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Editor’s Note 

In 1984, CCITT published Red Books on 
wide-ranging topics, including the X.25 
packet-switching standards. A set of revi¬ 
sions to the X Series, the Blue Books, was 
published in 1989. Since that time, stan¬ 
dards ratification and publication have 
been ongoing, continuous processes. Each 
future addition or revision to the X Series 
standards will be made available, as soon as 
they are finalized, in individual gray book¬ 
lets. Since the major building blocks of the 
X standards were completed by 1984, all 
post-1984 technical changes are relatively 
minor; they are discussed in this report, 
however. 


Report Highlights 

A packet switched network permits a user’s 
data terminal equipment (i.e., a PC, host 
computer, or terminal) to communicate 
with the equipment of other geographically 
dispersed users. Data must be presented 
to the network in a prescribed manner, 
however. A packet assembler/disassembler 
(PAD), also referred to as data circuit-ter¬ 
minating equipment (DTE), serves as a net¬ 
work entry/exit point, packetizing and de- 
packetizing data according to the rules 
specified by the X.3, X.28, X.29, X.21, 
X.25, and X.75 recommendations of the 
CCITT. 


Major developments in packet switching 
center around the development of ISDN- 
related technologies, such as fast packet 
switching and frame relay, which provide 
integration of voice, video, and data, and 
support much higher throughput than tra¬ 
ditional X.25 networks. ISDN’s relation¬ 
ship with traditional X.25 packet switching 
is also discussed. 
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In the early days of packet switching, each Public Data 
Network (PDN) defined its own network access protocol, 
which permitted an appropriately equipped computer to 
communicate with other devices on the network through a 
physical connection to the PDN. Each of these protocols 
used a multiplexing technique that enabled a computer to 
establish and maintain one or more virtual circuits to 
other network communicating equipment. No industry 
standard for packet switching existed, however, and most 
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computer manufacturers were reluctant to provide the 
necessary software to handle the variety of network access 
protocols. 

With the adoption of the X Series Recommendations 
by the CCITT in 1976, the PDNs could offer a standard 
network access protocol. The CCITT published revisions 
to these standards in 1984 and 1989. Since that time, the 
ratification and publication of revisions have become a 
continuous, ongoing process. 

This report focuses on Recommendations X.3, X.28, 
and X.29 (informally called the Interactive Terminal In¬ 
terface [ITI] standards); X.21; X.25; and X.75. 


Table 1. CCITT Recommendations—X Series 


CCITT 

Recommendation 

Description 

X.1 

International user classes of service irv 
public data networks: class 8 (2400 
bps); class 9 (4800 bps); class 10 
(9600 bps); or class 11 (48,000 bps) 

X.2 

International user facilities in public 
data networks 

X.3 

Packet assembly/disassembly (PAD) fa¬ 
cility in a public data network; lists op¬ 
tions and defaults for interactive 
asyn chronous terminal connection to 
X.25 packet networks 

X.4 

General structure of signals of Interna¬ 
tional Alphabet No. 5 (IA5) code for 
data transmission over public data 
networks (IA5 is described in CCITT 

V.3) 

X.20 

Interface between data terminal equip¬ 
ment (DTE) and data circuit-terminat¬ 
ing equipment (DCE) for async 
trans mission services on public data 
networks 

X.20 bis 

V.21 -compatible interface between DTE 
and DCE for async transmission ser¬ 
vices on public data network 

X.21 

General-purpose interface between 

DTE and DCE for synchronous opera¬ 
tion on public data networks 

X.21 bis 

For use on public data networks by 

DTE that are designed to interface to 
synchronous V-Series modems 

X.24 

List of definitions of interchange circuits 
between DTE and DCE on public data 
networks 

X.25 

Interface between DTE and DCE for ter¬ 
minals operating in the packet mode 
on public data networks 

X.26 

Electrical characteristics for unbalanced 
double-current interchange circuits for 
data communications equipment 


CCITT 

Recommendation 

Description 

X.27 

Electrical characteristics for balanced 
double-current interchange circuits for 
data communications equipment 

X.28 

DTE/DCE interface for asynchronous 
device access to the PAD facility of a 
public data network in the same 
country 

X.29 

Procedure for the exchange of control 
information and user data between a 
packet mode DTE and a PAD facility 

X.32 

Procedure for communications between 
users and packet networks through 
the switched telephone network and 
through circuit switched public data 
networks 

X.75 

Expanded X.25 recommendation for in¬ 
ternetwork communications between 
packet switched networks; interface is 
defined between two STEs (Signaling 
Terminal Equipments) that are a part 
of ISDEs (International Data Switching 
Exchanges), with expanded support 
for wideband links, extended sequenc¬ 
ing, and an expanded network utility 
field for international call 
establishment 

X.92 

Hypothetical reference connections for 
public synchronous data networks 

X.95 

Network parameters in public data 
networks 

X.96 

Call progress signals in public data 
networks 

X.121 

International numbering scheme for 
multinetwork communications contain¬ 
ing a 4-digit DNIX (Data Network Iden¬ 
tification Code), 3-digit area code, 5- 
digit host identification, a 0- to 2-digit 
subaddress 


NOVEMBER 1992 


© 1992 McGraw-Hill, Incorporated. Reproduction Prohibited. 
Datapro information Services Group. Deiran NJ 08075 USA 



DATAPRO 


Data Networking 


2720 

Standards 


1 


CCITT Packet Switched 
Networking Standards 
X Series 



In this reports 


Synopsis 


Packet Assembly/ 
Disassembly.3 

X.21 Interface 

Specifications.6 

Recommendation 

X.25.9 

Connections 

Between Packet Switched 
Data Networks.17 

Trends in Packet 
Switching.20 


Editor’s Note 

In 1984, CCITT published Red Books on 
wide-ranging topics, including the X.25 
packet-switching standards. A set of revi¬ 
sions to the X Series, the Blue Books, was 
published in 1989. Since that time, stan¬ 
dards ratification and publication have 
been ongoing, continuous processes. Each 
future addition or revision to the X Series 
standards will be made available, as soon as 
they are finalized, in individual gray book¬ 
lets. Since the major building blocks of the 
X standards were completed by 1984, all 
post-1984 technical changes are relatively 
minor; they are discussed in this report, 
however. 


Report Highlights 

A packet switched network permits a user’s 
data terminal equipment (i.e., a PC, host 
computer, or terminal) to communicate 
with the equipment of other geographically 
dispersed users. Data must be presented 
to the network in a prescribed manner, 
however. A packet assembler/disassembler 
(PAD), also referred to as data circuit-ter¬ 
minating equipment (DTE), serves as a net¬ 
work entry/exit point, packetizing and de- 
packetizing data according to the rules 
specified by the X.3, X.28, X.29, X.21, 
X.25, and X.75 recommendations of the 
CCITT. 


Major developments in packet switching 
center around the development of ISDN- 
related technologies, such as fast packet 
switching and frame relay, which provide 
integration of voice, video, and data, and 
support much higher throughput than tra¬ 
ditional X.25 networks. ISDN’s relation¬ 
ship with traditional X.25 packet switching 
is also discussed. 


—By Martin Dintzis 
Assistant Editor 


© 1992 McGraw-Hill, Incorporated. Reproduction Prohibited. 
Datapro Information Services Group. Delran NJ 08075 USA 


AUGUST 1992 








2 


Data Networking 


2720 

Standards 



Analysis 


In the early days of packet switching, each Public Data 
Network (PDN) defined its own network access protocol, 
which permitted an appropriately equipped computer to 
communicate with other devices on the network through a 
physical connection to the PDN. Each of these protocols 
used a multiplexing technique that enabled a computer to 
establish and maintain one or more virtual circuits to 
other network communicating equipment. No industry 
standard for packet switching existed, however, and most 
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computer manufacturers were reluctant to provide the 
necessary software to handle the variety of network access 
protocols. 

With the adoption of the X Series Recommendations 
by the CCITT in 1976, the PDNs could offer a standard 
network access protocol. The recommendations are con¬ 
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Packet Assembly/Disassembly 

Recommendations X.3, X.28, and X.29 define the proce¬ 
dures by which asynchronous terminals, computers, and 
other devices, often referred to as data terminal equipment 
(DTE), communicate with other devices via a packet 
switched network. Packet assemblers/disassemblers, also 
referred to as DTE, commonly serve as network entry/exit 
points. 

X.3 defines the basic and user-selectable functions of a 
packet assembler/disassembler (PAD). It also lists 22 pa¬ 
rameters necessary to characterize a specific device (e.g., 
bit rate, the escape character, and flow control technique). 
The proper setting of these values enables the PAD to cor¬ 
rectly interpret the communicating device and vice versa. 

X.28, a related standard, defines the procedures for 
character interchange and service initialization, the ex¬ 
change of control information, and the exchange of user 
data between an asynchronous terminal device and a PAD. 
X.29 defines the procedures for the exchange of PAD con¬ 
trol information and the manner in which user data is 
transferred between a packet mode DTE and a PAD or 
between two PADs. 

Recommendation X.3 

CCITT Recommendation X.3, Packet Assembly/Disas¬ 
sembly Facility in a Public Data Network , outlines the pro¬ 
cedures for packet assembly/disassembly in asynchronous 
transmissions. These functions can be programmed and 
built into a microprocessor-based “black box” that is 
placed between the terminal and the X.25 network at ei¬ 
ther the customer’s premises or the entry point of the net¬ 
work node. 

The PAD performs a number of functions, some of 
which allow it to be configured, by either an asynchronous 
terminal device or another (remote) PAD, so that its oper¬ 
ation is adapted to the asynchronous terminal’s character¬ 
istics. The PAD’s basic functions include: 

• The assembly of characters into packets; 

• The disassembly of the user data field; 

• Virtual call setup, clearing, resetting, and interrupt pro¬ 
cedures; 

• Generation of service signals; 

• A mechanism for forwarding packets when the proper 
conditions exist; 

• A mechanism for transmitting data characters, including 
start, stop, and parity elements; 

• A mechanism for handling a break signal from an asyn¬ 
chronous terminal; 

• Editing of PAD command signals; 

• A mechanism for setting and reading the current value of 
PAD parameters; 

• A mechanism for the selection of a standard profile (op¬ 
tional); 

• Automatic detection of data rate, code, parity, and oper¬ 
ational characteristics (optional); and 

• A mechanism for the remote DTE to request a virtual 
call between an asynchronous terminal and another DTE 
(optional). 

The PAD’s operation depends on the selectable values of 
internal variables called PAD parameters. A set of param¬ 
eters exists independently for each asynchronous terminal. 
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The current value (the binary representation of the deci¬ 
mal value) of each PAD parameter delimits the opera¬ 
tional characteristics of the related function. The initial 
value of each parameter is set according to a predeter¬ 
mined set of values, the initial standard profile. Twenty- 
two PAD parameters have been standardized by the 
CCITT. They are as follows: 

• PAD recall using a character —allows an asynchronous 
terminal to initiate an escape from the data transfer state 
or the connection-in-progress state in order to send PAD 
command signals. This parameter has the following se¬ 
lectable values: not possible, possible by character 1/0 
(DLE), or possible by a user-defined graphics character. 

• Echo —enables characters received from the asynchro¬ 
nous terminal to be interpreted by the PAD and trans¬ 
mitted back to the asynchronous terminal. Selectable 
values are no echo (0) and echo (1). 

• Selection of data forwarding characters —allows the asyn¬ 
chronous terminal to send defined sets of characters, 
which the PAD recognizes as an indication to complete 
the packet assembly and to forward a complete packet 
sequence as defined in X.25. The basic functions of this 
parameter are encoded and represented by a decimal 
value. The functions include no data forwarding charac¬ 
ter (represented by decimal 0); alphanumeric characters 
A-Z, a-z, and 0-9 (decimal 1); CR (decimal 2); ESC, BEL, 
ENQ, and ACK (decimal 4); DEL, CAN, and DC2 (dec¬ 
imal 8); ETX and EOT (decimal 16); HT, LF, VT, and 
FF (decimal 32); and all other characters in columns 0 
and 1 of International Alphabet No. 5 (IA5) not included 
in the above (decimal 64). 

• Selection of idle timer delay —permits the selection of the 
duration of a time interval between successive charac¬ 
ters. When data received from the asynchronous termi¬ 
nal exceeds this interval, the PAD terminates the assem¬ 
bly of a packet and forwards it as defined in the X.25 
protocol. 

• Ancillary control —defines flow control between the 
PAD and the asynchronous terminal. Decimal 0 repre¬ 
sents no use of X-on (DC1) and X-off (DC3); decimal 1 
represents use of X-on/X-off (data transfer); and decimal 
2 represents the use of X-on/X-off (data transfer and 
command). 

• Control of PAD service signals —provides the asynchro¬ 
nous terminal with the capability to decide whether and 
in what format PAD service signals are transmitted. 

• Selection of operation of the PAD on receipt of the break 
signal —after receiving a break signal from the asynchro¬ 
nous terminal, the PAD may do nothing, send an inter¬ 
rupt packet to a packet mode DTE or another PAD, reset, 
or send an indication of break PAD message to a packet 
mode DTE or another PAD. 

• Discard output —permits a PAD to discard the content of 
user sequences in packets rather than disassembling and 
transmitting them to the asynchronous terminal. Selec¬ 
tions include normal data delivery or discard output. 

• Padding after carriage return —permits the PAD to auto¬ 
matically insert padding characters in the character 
stream sent to the asynchronous terminal after the occur¬ 
rence of a carriage return character. This enables the 
asynchronous terminal printing device to perform the 
carriage return function correctly. A value between 0 and 
255 indicates the number of padding characters the PAD 
will generate. 
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• Line folding —permits the PAD to automatically insert 
appropriate format effectors in the character stream sent 
to the asynchronous terminal. No line folding or a prede¬ 
termined maximum number of graphics characters per 
line may be selected. 

• Binary speed —a read-only parameter that neither DTE 
can change. It enables the packet mode DTE to access a 
characteristic (known by the PAD) of the asynchronous 
terminal device. Speeds from 50 bps to 64K bps are rep¬ 
resented. 

• Flow control of the PAD by the start/stop mode DTE — 
governs flow control between the asynchronous terminal 
and the PAD. The asynchronous terminal transmits spe¬ 
cial characters to indicate whether it is ready to accept 
characters from the PAD. In IA5, these special charac¬ 
ters switch an ancillary transmit device on and off. Dec¬ 
imal 0 represents no use of X-on (DC1) and X-off (DC3); 
decimal 1 represents use of X-on/X-off. 

• Line-feed insertion after carriage return —permits the 
PAD to automatically insert a line-feed character in the 
character stream sent to or received from the asynchro¬ 
nous terminal or after echo of each carriage return char¬ 
acter. This function applies only in the data transfer 
state. 

• Line-feed padding —permits the PAD to automatically 
insert padding characters in the character stream trans¬ 
mitted to the asynchronous terminal after the occurrence 
of a line-feed character. This enables the asynchronous 
terminal printing mechanism to perform the line-feed 
operation correctly. This function applies only in the 
data transfer state. 

• Editing —enables character delete, line delete, and line 
display editing capabilities. During the PAD command 
state , the editing function is always available; use or no¬ 
nuse of the editing function in the data transfer state is 
selectable. 

• Character delete, line delete, and line display —all editing 
functions represented by one user-selectable character 
from IA5. 

• Editing PAD service signals —enable the asynchronous 
terminal to edit PAD service signals for printing devices 
and display terminals; also used for editing via one char¬ 
acter from IA5. Editing is not selectable. 

• Echo mask —when echo is enabled, echo mask designates 
that selected defined groups of characters sent by the 
asynchronous terminal are not transmitted back. The 
following may be selected: no echo mask; no echo of CR; 
no echo of LF; no echo of VT, HT, and FF; no echo of 
BEL and BS; no echo of ESC and ENQ; no echo of ACK, 
NAK, STX, SOH, EOT, ETB, and ETX; no echo of edit¬ 
ing characters; or no echo of all other characters. 

• Parity treatment —permits the PAD to check parity in 
the datastream from the asynchronous terminal and/or 
generate parity in the datastream to the asynchronous 
terminal. No parity checking or generation, parity check¬ 
ing, or parity generation are selectable. 

• Page wait —allows the PAD to suspend transmission of 
additional characters to the asynchronous terminal after 
the PAD has transmitted a specified number of line-feed 
characters. 
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Recommendation X.28 

CCITT Recommendation X.28, titled DTE/DCE Inter¬ 
face for a Start/Stop Mode Data Terminal Equipment Ac¬ 
cessing the Packet Assembly/Disassembly Facility (PAD) in 
a Public Data Network Situated in the Same Country , de¬ 
scribes the interfacing procedures that allow the PAD to be 
connected to an asynchronous terminal. X.28 covers four 
areas: 

• Procedures to establish an access information path be¬ 
tween an asynchronous terminal and a PAD; 

• Procedures for character interchange and service initial¬ 
ization between an asynchronous terminal and a PAD; 

• Procedures for the exchange of control information be¬ 
tween an asynchronous terminal and a PAD; and 

• Procedures for the exchange of user data between an 
asynchronous terminal and a PAD. 

Modems standardized for use on public switched or leased 
line facilities establish the procedures for providing an ac¬ 
cess path (DTE/DCE interface). Procedures for both V and 
X Series interfaces are defined. 

Transmission speeds up to 1200 bps are specified for 
V-Series interfaces; they are in accordance with either the 
V.21, V.22, or Y.23 standard, depending on facility type 
and speed. The V-Series specifications define the proce¬ 
dures for setting up and disconnecting the access informa¬ 
tion path by both the DTE and the PAD. 

X-Series interfaces also are used with switched or leased 
line facilities. The physical characteristics for the DTE/ 
DCE interface are specified in X.20 or X.20 bis. Proce¬ 
dures for setting up and disconnecting the path by both the 
DTE and the PAD are defined. 

X.28 specifies procedures for character interchange and 
service initialization between an asynchronous terminal 
and a PAD. Characters sent and received must conform to 
IA5. The PAD transmits and expects to receive only eight- 
bit characters. The eighth bit, the last bit preceding the 
stop element, is used for parity checking. 

X.28 describes the action the PAD takes when the value 
of parameter 21 (X.3, parity treatment) is set to 0, 1, 2, or 
3. If parameter 21 is set to 0, the PAD inspects only the 
first seven bits and ignores the eighth bit. When parameter 
21 is set to 1, the PAD treats the eighth bit of the character 
as a parity bit and checks this bit against the type of par¬ 
ity—odd, even, space (0), or mark (1)—used between the 
PAD and the asynchronous terminal. If it is set to 2, the 
PAD replaces the eighth bit of the characters to be sent to 
the terminal with the bit that corresponds to the type of 
parity used between the PAD and terminal. When the 
value is set to 3, the PAD checks the parity bit for charac¬ 
ters received from the asynchronous terminal and gener¬ 
ates the parity bit for characters to be sent to the asynchro¬ 
nous terminal (as in values 1 and 2). 

Once the access information path is established, the 
asynchronous terminal and the PAD exchange binary 1 
across the interface. This places the interface in the active 
link state (state 1). When the interface is in the active link 
state, the DTE transmits a sequence of characters that in¬ 
dicates service request (state 2) and initializes the PAD. 
The service request permits the PAD to detect the data 
rate, code, and parity used by the asynchronous terminal 
(DTE) and to select the initial profile of the PAD. The ser¬ 
vice request may be bypassed, if the terminal is connected 
to the PAD via a leased line and the PAD knows the speed, 
code, and initial profile of the terminal or if a default value 
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is used. After the request service signal is transmitted, the 
DTE transmits binary 1, which places the interface in the 
DTE waiting state (state 3A). If parameter 6 (X.3, control 
of PAD service signals) is set to 0, the interface immedi¬ 
ately enters the PAD waiting state (state 5) after receipt of 
service request. If parameter 6 is set to other than 0, the 
PAD transmits the PAD identification PAD service signal 
(indicates PAD and port identity; is network dependent), 
and the interface enters the service ready state (state 4). 
The DTE then transmits a selection PAD command signal 
(state 6), and the PAD transmits an acknowledgment PAD 
service signal, followed by binary 1, which places the inter¬ 
face in the connection-in-progress state (state 7). 

If parameter 6 is 0, the PAD will not transmit PAD 
service signals. In this case, the interface is placed in the 
connection-in-progress state after receipt of a valid selec¬ 
tion PAD command signal. 

Once the DTE receives the PAD service signal (state 8) 
or a sequence of signals in response to a PAD command 
signal, the interface is placed in either the PAD waiting 
state (state 5) or the data transfer state (state 9). 

A fault condition exists if a valid service request signal is 
not received by the PAD within a selectable number of 
seconds after the transmission of binary 1. If a fault condi¬ 
tion occurs, the PAD performs clearing by disconnecting 
the access information path. 

The procedures for the exchange of control information 
between an asynchronous terminal and a PAD include 
PAD command signals, PAD service signals, break signals, 
and prompt PAD service signals. PAD command signals 
flow from the DTE to the PAD; they set up and clear a 
virtual call, select a standard profile (PAD parameters) 
that is either CCITT or network defined, request current 
values of PAD parameters, send an interrupt requesting 
circuit status, and reset a virtual call. PAD service signals 
flow from the PAD to the DTE; they transmit call progress 
signals, acknowledge PAD command signals, and transmit 
operating information of the PAD to the terminal. Either 
the PAD or the terminal can transmit the break signal. It 
provides signaling without losing character transparency. 
The prompt PAD service signal indicates the PAD’S readi¬ 
ness to receive a PAD command signal. 

The temporary storage of characters in an editing buffer 
provides editing functions in the PAD. These functions 
permit the asynchronous terminal to edit characters input 
to the PAD before the PAD processes them. They include 
character delete, line delete, and line display. Character 
delete removes the last character in the editing; line delete 
removes the contents of the editing buffer. Line display 
causes the PAD to send a format effector followed by the 
contents of the editing buffer to the terminal. 

Procedures for the exchange of user data between an 
asynchronous terminal and a PAD apply during the data 
transfer state. The values of the parameters set in X.3 de¬ 
termine which characters are transmitted during the data 
transfer state. For example, if parameters 1 (PAD recall 
using a character), 12 (flow control of the PAD by the start/ 
stop mode DTE), 15 (editing), and 22 (page wait) are set to 
0, any character sequence may be transmitted by the asyn¬ 
chronous terminal for delivery to the remote DTE during 
the data transfer state. 

User data is sent to the asynchronous terminal in octets 
(eight-bit characters) at the appropriate transmission rate 
for the asynchronous terminal; the start/stop bits are 
added to the data characters. Octets are assembled into 
packets (see X.25) and forwarded when enough data has 


been received to fill a packet, when the maximum assem¬ 
bly timer delay period has elapsed, when a data forwarding 
character is transmitted, or when a break signal is trans¬ 
mitted (parameter 7 is set to other than 0). 

Recommendation X.29 

CCITT Recommendation X.29, titled Procedures for the 
Exchange of Control Information and User Data Between a 
Packet Assembly/Disassembly Facility (PAD) and a Packet 
Mode DTE or Another PAD , provides the final step. X.29 
describes the interfacing procedures that allow the PAD to 
communicate with the X.25 network. It defines the proce¬ 
dures for the exchange of PAD control information and 
the manner in which user data is transferred between a 
packet mode DTE and a PAD or between two PADs. 

Recommendation X.29 specifies that control informa¬ 
tion and user data are exchanged between a PAD and a 
packet mode DTE or between PADs using the data fields 
described in X.25. Interface characteristics—mechanical, 
electrical, functional, and procedural—are also defined as 
in X.25. 

X.29 specifies that the call user data field of an incom¬ 
ing call or call request packet going to/from the PAD or the 
packet mode DTE must consist of protocol identifier and 
call data fields. A call request packet need not contain a 
call user data field to be accepted by the PAD. If the call 
user data field is present, the PAD transmits it, unchanged, 
to its destination. 

A call data field’s octets consist of user characters sent 
from the DTE to the PAD during the call establishment 
phase. This field is limited to 12 octets. The octet’s bits are 
numbered 8 to 1; bit 1, the low order bit, is transmitted 
first. 

Bits 8, 7, 6, and 5 of octet 1 of a user data field of com¬ 
plete packet sequences are the control identifier field. This 
field, which consists of four octets, identifies the facility to 
be controlled. The control identifier field coding for mes¬ 
sages to control a PAD for an asynchronous terminal is 
0000. When the control identifier field is set to 0000, bits 
4, 3, 2, and 1 of octet 1 are defined as the message code 
field, which is used to identify specific types of PAD mes¬ 
sages. 

User sequences perform data exchange. They are trans¬ 
ferred in the user data fields of complete packet sequences 
with the Q bit set to 0. Only one user sequence exists per 
complete packet sequence. The PAD transmits all data 
packets with the D bit set to 0. The DTE sends a data 
packet to the PAD with the D bit set to 1. When the PAD 
receives a data packet with the D bit set to 1, it sends the 
corresponding acknowledgment. The PAD may reset the 
virtual call, if it does not support the D bit procedure. 

Control information is exchanged via PAD messages , 
which contain a control identifier field and a message code 
field that may be followed by a parameter field. PAD mes¬ 
sages are transferred in the user data fields of complete 
packet sequences with the Q bit set to 1. Only one PAD 
message exists per complete packet sequence. The PAD 
sends all data packets with the D bit set to 0. The DTE may 
send data packets to the PAD with both the D bit and the 
Q bit set to 1. When the PAD receives a data packet with 
both the Q and D bits set to 1, the corresponding acknowl¬ 
edgment is transmitted. The PAD may reset the virtual call 
if it does not support the D bit procedure. (Figure 5 shows 
the bit positions for the Q and D bits.) 
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The PAD forwards a data packet when a set, read, or set 
and read PAD message is received or when any of the con¬ 
ditions listed in X.28 exist (e.g., enough data has been re¬ 
ceived to fill a packet, the maximum assembly timer delay 
period has elapsed, or a data forwarding character is trans¬ 
mitted). The PAD never forwards an empty data packet. 

By sending a set , read, or set and read message to the 
PAD, one can read and change the current values of PAD 
parameters. Upon receipt of one of these messages, the 
PAD delivers to the DTE any previously received data be¬ 
fore it acts on the PAD message. The PAD responds to a 
read or set and read PAD message by sending a parameter 
indication PAD message, which contains a parameter field 
listing parameter references and current values. Set allows 
the changing of parameters. 

X.29 also discusses invitation to clear procedures, 
which are used to request that the virtual call be cleared by 
the PAD; interrupt and discard procedures, which are used 
to indicate that the asynchronous terminal has requested 
that the PAD discard received user sequences; reset proce¬ 
dures, as defined in X.25; error handling procedures by the 
PAD, which define the actions to be taken by the PAD 
when errors are detected; and procedures for inviting the 
PAD to reselect the called DTE (optional), which are used 
by a packet mode DTE to request that the PAD clear the 
virtual call. 


X.21 Interface Specifications 

The trends in communications engineering lean toward 
all-digital networks and the integration of voice and data. 
Prospective users of these digital, integrated networks are 
concerned about an interface that can provide access to 
voice, data, video teleconferencing, and related services. 
Currently, a wide variety of connectors, electrical stan¬ 
dards, and user procedures for various services and net¬ 
works exists—leading to almost insurmountable technical 
and economical problems. Therefore, it is likely that stan¬ 
dards organizations will develop a universal service access 
interface. Although it would require certain extensions, 
X.21 is currently the most likely to become a future stan¬ 
dard for a universal interface in distributed system imple¬ 
mentations. 

CCITT Recommendation X.21, Interface Between 
Data Terminal Equipment (DTE) and Data Circuit-Termi¬ 
nating Equipment (DCE) for Synchronous Operation on 
Public Data Networks, defines the physical characteristics 
and control procedures for an interface between DTEs and 
DCEs. 

X.21 is the designated interface for CCITT Recommen¬ 
dation X.25, a packet-switching protocol. X.21 can also be 
used in a non-packet switched environment. At least two 
X.21-based public data circuit switched networks are cur¬ 
rently implemented, one in Scandinavia and one in Japan. 

The X.21 standard has not gained wide acceptance in 
the United States. The reluctance in the U.S. to embrace 
the X.21 standard is due in part to the firm entrenchment 
of RS-232-C. Another factor is the cost of implementing 
X.21. Since X.21 transmits and interprets coded character 
strings, more intelligence must be built into the interface, 
at a higher cost than traditional pin-per-function inter¬ 
faces. 

Certain characteristics of X.21 should ensure a more 
widespread acceptance in the coming years. One immense 
advantage X.21 has over traditional interfaces is its capa¬ 
bility to assign an almost unlimited number of functions, 
because there are no functional boundaries associated with 
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connector size. Also, X.21 offers a much more sophisti¬ 
cated level of control over the communications process. 
Another important feature of X.21 is its inherent dialing 
functions, including the provision for reporting the rea¬ 
sons why a call was not completed. This eliminates the 
need for a separate data call interface, such as RS-232-C’s 
companion RS-366-A, and in switched facilities, results in 
improved response times. 

Another important aspect is its relationship to X.25. As 
the packet-switching technique becomes more widely im¬ 
plemented, the demand will be greater for equipment to 
meet the X.21 standard. Internationally, the combination 
of X.21, the ISO HDLC protocol, and X.25 has been used 
to form an effective communications path. Another boost 
for X.21 is IBM’s recognition. 

X.21 has some shortcomings. It does not permit the 
transmission of control information during data transfer. 
Also, it precludes the insertion of data encryption hard¬ 
ware between the DTE and the DCE. Another drawback is 
the need to modify the DTE/DCE master/slave protocol 
techniques and to supply special crossover cables to facili¬ 
tate DTE-to-DTE or DCE-to-DCE interconnection. 

X.21 uses a different interfacing technique than that 
which is normally associated with physical-level inter¬ 
faces. Instead of assigning each function a specific pin on 
the connector (e.g., CCITT V.24 and EIA RS-232-C), X.21 
assigns coded character strings to each function. 

The following is a summary of the X.21 standard, in¬ 
cluding the functional descriptions of the interchange cir¬ 
cuits, phases of operation, electrical characteristics, and 
mechanical characteristics. 

Functional Descriptions of Interchange Circuits 

Four types of X.21 interchange circuits are defined: 
Ground, Data Transfer, Control, and Timing. These cir¬ 
cuits, outlined in Table 2, are described below. 

Ground and Common Return Circuits —include two 
types of common return circuits, DTE Common Return 
and DCE Common Return, and one ground circuit, Signal 
Ground. 

Signal Ground (Circuit G) establishes the common ref¬ 
erence potential for unbalanced double-current inter¬ 
change circuits. If required, it reduces environmental sig¬ 
nal interference. 

Lowering signaling rates may require two common re¬ 
turn conductors. In this case, two circuits, DTE Common 
Return (Circuit Ga) and DCE Common Return (Circuit 
Gb), are necessary. For a further explanation of these cir¬ 
cuits, see the Electrical Characteristics section of this re¬ 
port. 

Data Transfer Circuits —include two Transmit and Re¬ 
ceive data transfer circuits. 

Transmit (Circuit T) transfers signals from the DTE to 
the DCE during the data transfer phase. It also transfers 
call control signals to the DCE during call establishment 
and other call control phases. 

Receive (Circuit R) receives signals transmitted by the 
DCE from a remote DTE during the data transfer phase. 
This circuit also transfers call control signals from the 
DCE during the call establishment and other call control 
phases. 

Control Circuits —include Control and Indication cir¬ 
cuits. 

Control (Circuit C) transmits signals that control the 
DCE for a particular signaling process. The representation 
of this signal requires additional coding of the Transmit 
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Figure 1. 

Quiescent States 



Definition?; 


* 



* 


n State number 
t Signal on T circuit 

c Signal on C circuit 

r Signal on R circuit 

i Signal on I circuit 

I Transition with indication 
1 of whether DTE or DCE 
▼ is responsible for transition 


The above diagram indicates transitions that are allowed in X.21 networks. Other transitions are possible and may be allowed in 
some networks. See Table 3 for a listing of possible transitions. 


circuit, as specified for the procedural characteristics of 
the interface. During the data phase, Circuit C remains in 
the ON condition. 

Indication (Circuit I) indicates the call control process 
to the DTE. The representation of this signal requires ad¬ 
ditional coding of the Receive circuit. When Circuit I is 
on, it signifies that signals on the Receive circuit contain 
information from the remote DTE. When Circuit I is off, it 
signifies a control signaling condition, defined by the Cir¬ 
cuit R bit patterns, as specified by the procedural charac¬ 
teristics of the interface. 

Timing Circuits —includes Signal Element Timing and 
Byte Timing. 

Signal Element Timing (Circuit S) provides the DTE 
with signal element timing information. For this function, 
Circuit S turns on and off for nominally equal periods of 
time. 

X.21 defines different roles for the DTE and DCE in 
regard to signal element timing. During the off-to-on tran¬ 
sition, the DTE presents a binary signal on Circuit T and a 
condition on Circuit C. The DCE presents a binary signal 
on Circuit R and a condition on Circuit I during the off- 
to-on transition. The DCE transfers the signal element 
timing across the interface as long as the timing source is 
capable of generating this information. 

Byte Timing (Circuit B) provides the DTE with eight-bit 
timing information for synchronous transmission. Use of 
this circuit is not mandatory. Circuit B turns off whenever 
Circuit S is in the ON condition, indicating the last bit of 


the eight-bit byte. At all other times within the period of 
the eight-bit byte, Circuit B remains on. 

Phases of Operation 

The X.21 standard defines four phases of operation: the 
Quiescent Phase, the Call Control Phase, the Data Trans¬ 
fer Phase, and the Clearing Phase. 

Each step of the operational phases places the DTE and 
DCE in a certain state. See Table 3 for a listing of these 
states and their associated signals on the interchange cir¬ 
cuits. 

Quiescent Phase —the quiescent phase is the period dur¬ 
ing which the DTE and the DCE signal their capability to 
enter the call control phase or the data transfer phase. It is 
characterized by the appearance of basic quiescent signals 
from the DTE and DCE. Various combinations of these 
quiescent signals result in different interface states, or qui¬ 
escent states. 

There are three DTE quiescent signals. DTE Ready in¬ 
dicates the readiness of the DTE to enter the other opera¬ 
tional phases. DTE Uncontrolled Not Ready indicates the 
DTE is unable to enter certain operational phases, usually 
due to an abnormal condition. DTE Controlled Not Ready 
indicates that although the DTE is operational, it is tempo¬ 
rarily unable to accept incoming calls for circuit switched 
service. 

There are two DCE quiescent signals: DCE Ready and 
DCE Not Ready. DCE Ready indicates the DCE is ready 
to enter operational phases. DCE Not Ready indicates that 
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no service is available; it is also signaled whenever possible 
during network fault conditions and during the period 
when test loops are activated. 

There are six quiescent states: 

• Ready 

• DTE Controlled Not Ready, DCE Ready 

• DTE Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Not Ready 

• DTE Controlled Not Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Ready 

See Figure 1 for a diagram of the quiescent states and the 
transitions that are allowed between these states. 

Call Control Phase —the call control phase for circuit 
switched service contains many elements and procedures. 
Characters used for call control are selected from IA5, a 
seven-bit plus parity international code outlined in CCITT 
Recommendation V.3. Each call control sequence to and 
from the DCE is preceded by two or more continuous SYN 
characters. For error checking of call control characters, 
odd parity is specified. 

The following elements of the call control procedure are 
outlined in X.21: events of call control procedures, unsuc¬ 
cessful call, call collision, direct call, and facility registra¬ 
tion/cancellation procedure. These elements are summa¬ 
rized below. 

The events of the call control procedures include the 
following: 

• Call Request , signaled by the DTE to indicate a request 
for a call. 

• Proceed to Select , used when the network is prepared to 
receive selection information. It is transmitted by the 
DCE to the DTE within three seconds of the call request 
signal. 

• Selection Signal Sequence , transmitted by the DTE. A 
selection sequence consists of a facility request block, an 
address block, a facility request block followed by an ad¬ 
dress block, or a facility registration/cancellation block. 
A facility request block comprises one or more facility 
request signals, which consist of a facility request code 
containing one or more facility parameters. An address 
block contains one or more address signals. Address sig¬ 
nals consist of either a full address signal or an abbrevi¬ 
ated address signal. 

• DTE Waiting. 

• Incoming Call , indicated by the DCE. In response, the 
DTE signals Clear Request, DTE Uncontrolled Not 
Ready, or DTE Controlled Not Ready. 

• DCE Waiting. 

• Call Progress Signal Sequence is transmitted by the DCE 
to the calling DTE to indicate that circumstances have 
arisen to prevent the connection from being established, 
to report the progress made toward establishing the call, 
or to signal that problems have been detected and that 
the call needs to be cleared and reset. 

• DCE-Provided Information Sequence , transmitted from 
the DCE to the calling DTE. It consists of DCE-provided 
information blocks, such as line identification and 
charging information. Line Identification is transmitted 
by the DCE to the calling DTE during the DCE-Provided 
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Information state immediately after all call progress sig¬ 
nals, if any, are transmitted. Both calling and called line 
identification are optional. Line identification consists 
of the international data number, as assigned in CCITT 
Recommendation X. 121, International Numbering Plan 
for Public Data Networks . The DCE transmits Charging 
Information during the DCE-Provided Information 
state. It informs the subscriber of either the monetary 
charges for a call, the duration of the call, or the number 
of units used during the call. 

• Connection-In-Progress , indicated by the DCE. 

• Ready for Data , transmitted by the DCE when the con¬ 
nection is available for data transfer between DTEs. 

An unsuccessful call occurs when a required connection 
cannot be established. In this case, the DCE indicates the 
failure and its reason to the calling DTE through a call 
progress signal. 

A call collision can occur in one of two ways: a DTE 
detects a call collision when it receives Incoming Call in 
response to Call Request. A DCE detects a call collision 
when it receives Call Request in response to Incoming 
Call. When the DCE detects a call collision, it will indicate 
Proceed to select and cancel the incoming call. 

The DTE indicates a request for a direct call by signal¬ 
ing DTE Waiting after receiving the Proceed to Select sig¬ 
nal. If necessary, the DTE may choose an addressed call by 
presenting the correct Selection signal. 

The facility registration/cancellation procedure is op¬ 
tional. A facility registration/cancellation signal consists of 
up to four elements in order: facility request code, indica¬ 
tor, registration parameter, and address signal. Not all of 
these elements are required in the facility registration/can¬ 
cellation signal. Also, a number of these signals may be 
linked to form a block. In response to acceptance or rejec¬ 
tion of the facility registration/cancellation action, the net¬ 
work provides the appropriate Call Progress Signal. 

Data Transfer Phase —when the DTE is in the data 
transfer phase, any bit sequence may be transmitted. X.21 
defines the data transfer phase for three types of connec¬ 
tions: switched; leased, point to point; and leased, central¬ 
ized multipoint. 

For operation over switched facilities, the DTE may 
send bits to a corresponding DTE after receiving the 
Ready for Data signal. During data transfer, control and 
interchange circuits are in the ON condition, and data is 
transmitted over the transmit and receive circuits. Data 
transfer may be terminated by clearing , which is defined 
below. 

Two basic signals are used for operation over leased, 
point-to-point facilities. Send Data transmits data by the 
DTE on Circuit T; the remote DTE’s Receive Data signal 
receives data over Circuit R. To terminate the data trans¬ 
fer, the DTE signal places its transmit circuit in the binary 
1 condition. The DCE indicates termination of data trans¬ 
fer by placing its receive circuit in the binary 1 condition, 
its control circuit in the OFF condition, and its indications 
circuit in the OFF condition. 

Both the central and remote DTEs use the Send Data 
and Receive Data signals for operation over leased, mul¬ 
tipoint facilities. The central DTE delivers data transmit¬ 
ted to all remote DTEs; remote DTEs (one at a time) trans¬ 
mit data to the central DTE. A remote DTE may send data 
to the central DTE while the central DTE is sending to all 
remote DTEs. 
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Table 2 

. CCITT X.21 Interchange 

Circuits 





Direction 


Inter- 

Name to DCE 

from DCE 

Circuit 

change 

Circuit 



Type 

G 

Signal 
ground or 




common 

return 



Ga 

DTE com- X 
mon return 


Ground 

Gb 

DCE com¬ 
mon return 

X 


T 

Transmit X 


Data 

Transfer 

R 

Receive 

X 


C 

Control X 



1 

Indication 

X 

Control 

S 

Signal ele¬ 
ment timing 

X 


B 

Byte timing 

X 

Timing 


Clearing Phase —either the DTE or the DCE may ini¬ 
tiate clearing. The DTE indicates its desire to enter the 
clearing phase by transmitting DTE Clear Request. The 
DCE responds by signaling DCE Clear Confirmation , fol¬ 
lowed by DCE Ready. 

Clearing by the DCE takes place when it transmits DCE 
Clear Indication. The DTE responds with the DTE Clear 
Confirmation signal, followed by the DCE signaling DCE 
Ready. 

Electrical Characteristics 

X.21 uses two types of electrical characteristics, each for 
different system requirements. 

For synchronous operation at 9600 bps and below, the 
interchange circuits at the DCE side of the interface must 
comply with CCITT Recommendation X.21. The DTE 
side can comply with either X.27 or another CCITT Rec¬ 
ommendation, X.26. For synchronous operation at signal¬ 
ing rates above 9600 bps, interchange circuits at both the 
DTE and DCE sides of the interchange circuits must com¬ 
ply with X.27. 

X.26 is defined in CCITT Standard V.10. It describes 
the electrical characteristics for unbalanced interchange 
circuits. X.26 calls for both a DTE and DCE common 
grounding arrangement. The maximum suggested cable 
length is 1,000 meters, and the maximum data rate is 100K 
bps. 

X.27 is defined by CCITT Standard V.ll, which de¬ 
scribes the electrical characteristics for balanced opera¬ 
tion. Maximum suggested cable length is 1,000 meters, 
and the maximum data rate is 10M bps. 

Mechanical Characteristics 

The mechanical characteristics for X.21 are outlined in the 
ISO Standard 4903, approved by the International Organi¬ 
zation for Standardization (ISO). The standard, entitled 
Data Communication — 15-pin DTE/DCE Interface Con¬ 
nector and Pin Assignments , was published in June 1980. 
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ISO 4903 assigns connector pin numbers to a 15-pin 
interface between DTE and DCE equipment. Table 4 pre¬ 
sents a chart of these X.21 pin assignments as they relate to 
the X.26 and X.27 standards. 

X.21 Bis 

Although X.21 is the specified interface for X.25, alterna¬ 
tive interfaces also exist. One of these is X.21 bis. 

CCITT Recommendation X.21 bis, the physical and 
functional equivalent to CCITT V.24, defines 25 inter¬ 
change circuits between DTEs and DCEs. CCITT V.24 is 
compatible with EIA Standard RS-232-C. The X.21 bis 
recommendation, accepted as the interim interface for 
X.25, will be gradually replaced by X.21 as more equip¬ 
ment is manufactured to meet X.21 specifications. 


Recommendation X.25 

The development of Recommendation X.25 was stimu¬ 
lated by the need for a standard interface between the 
packet-switching networks already developed or being de¬ 
veloped by many industrial nations and by the require¬ 
ment that no terminal equipment be denied access to 
packet switched services. 

X.25 is a dynamic standard with many variations in the 
U.S. and abroad. Currently, X.25-based packet switched 
networks exist in Australia, Austria, Belgium, Canada, 
France, Ireland, Germany, Hong Kong, Italy, Japan, Mex¬ 
ico, the Netherlands, Portugal, Singapore, the Soviet 
Union, South Africa, Spain, Switzerland, the United King¬ 
dom, and the United States. Since X.25 is a dynamic stan¬ 
dard with many extensions and optional features, these 
networks are not totally compatible with one another. 
Those located in Europe have the highest level of mutual 
compatibility. 

Since the establishment of X.25, additional user-level 
protocols have been developed. These protocols provide 
the interfaces between different types of terminals and the 
X.25 interface. X.3, X.28, and X.29, informally called the 
Interactive Terminal Interface (ITI), were the first of the 
protocols to interface to X.25. They relate to the support of 
asynchronous, low-speed terminals by packet switched 
networks. These are logical complements to X.25 because 
they permit specific sets of terminals to interface to the 
packet networks using the X.25 interface. 

The X.25 interface standard provides for the connec¬ 
tion of terminals and computers to public packet-switch¬ 
ing networks. X.25 outlines three layers of operation: the 
Physical Layer, the Link Layer, and the Packet Layer. 
These layers parallel the bottom three layers of the ISO 
Reference Model for Open Systems Interconnection. The 
Physical Layer calls for CCITT X.21 as the physical and 
electrical interface but accepts X.21 bis, a functional 
equivalent of RS-232-C, as an interim standard. The Link 
Layer uses the procedures of the HDLC protocol standard. 
The Packet Layer defines procedures for constructing and 
controlling a data packet. 

The 1984 revision of Recommendation X.25 added 
specifications for X.21 access and expanded the potential 
of packet operations, allowing users to actively gain access 
to the X.25 port, identify themselves, and validate their 
connection through passwords. This change reoriented the 
X.25 standard toward switched access through both X.21 
facilities and the public telephone network. It now sup¬ 
ports X.32 with regard to the public switched telephone 
network or a circuit switched public data network, dial-in 
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Table 3. X.21 States: Names, Signalling, and Transitions 

Signals on T,C and R,l Circuits Transitions* 

Phase 


State 

Number State Name 

of 

Opera¬ 

tion 

T 

c 

R 

1 

DTE 
to state 
number 

DCE 
to state 
number 

1 

Ready 

Q 

1 

OFF 

1 

OFF 

2,13S,14,24 

8,13R,18 

2 

Call request 

CC 

0 

ON 

1 

OFF 

— 

3,15 

3 

Proceed-to-select 

CC 

0 

ON 

+ 

OFF 

4,15 

— 

4 

Selection signal 

CC 

IA5 

ON 

+ 

OFF 

5 

— 

5 

DTE Waiting 

CC 

1 

ON 

+ 

OFF 


6A,11,12 

6A 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

— 

7,10,11,12 

6B 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

— 

10 bis, 11,12 

7 

Call progress signal 

CC 

1 

ON 

IA5 

OFF 

— 

6A,10,11,12 

8 

Incoming call 

CC 

1 

OFF 

BEL 

OFF 

15,9 

— 

9 

Call accepted 

CC 

1 

ON 

BEL 

OFF 

— 

6B,11,12 

10 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

— 

6A,11,12 

10 bis 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

— 

6B,11,12 

11 

Connection in progress 

CC 

1 

ON 

1 

OFF 

— 

12 

12 

Ready for data 

CC 

1 

ON 

1 

ON 

— 

13 

13 

Data transfer 

DT 

D 

ON 

D 

ON 

13R 

13S.DCE 









not ready 

13R 

Receive data 

DT 

1 

OFF 

D 

ON 

13 

1 

13S 

Send data 

DT 

D 

ON 

1 

OFF 

7 

13 

14 

DTE Controlled not ready, DCE 









ready 

Q 

01 

OFF 

1 

OFF 

1,24 

23 

15 

Call collision 

CC 

0 

ON 

BEL 

OFF 

— 

3 

16 

DTE Clear request 

C 

0 

OFF 

X 

X 

— 

17 




(see 









Note) 






17 

DCE Clear confirmation 

C 

0 

OFF 

0 

OFF 

_ 

21 

18 

DTE Ready, DCE Not ready 

Q 

1 

OFF 

0 

OFF 

22 

1 

— 

DCE Not ready 

Q 

D 

ON 

0 

OFF 

— 

1,13,13S 

19 

DCE Clear indication 

C 

X 

X 

0 

OFF 

20 

— 




(see 









Note) 






20 

DTE Clear confirmation 

C 

0 

OFF 

0 

OFF 


21 

21 

DCE Ready 

C 

0 

OFF 

1 

OFF 

1 

— 

22 

DTE Uncontrolled not ready, DCE 









not ready 

Q 

0 

OFF 

0 

OFF 

18 

24 

23 

DTE Controlled not ready, DCE not 








ready 

Q 

01 

OFF 

0 

OFF 

18,22 

14 

24 

DTE Uncontrolled not ready, DCE 









ready 

Q 

0 

OFF 

1 

OFF 

1 

22 

Any 









state 









(see 









Note) 



X 

X 

X 

X 

16 

19 


*AII other transitions are considered invalid. 

Note: DCE Clear indication or DTE Clear request may be entered from any state except Ready. 


Key to Table: 

Q—Quiescent Phase 
CC—Call Control Phase 
DT—Data Transfer Phase 
T—Transmit interchange circuit 
C—Control interchange circuit 
R—Receive interchange circuit 
I—Indication interchange circuit 


0 and 1—Steady binary conditions 
01—Alternate binary 0 and binary 1 
X—Any value 

OFF—Continuous off (binary 1) 

ON—Continuous on (binary 0) 

IA5—Characters from CCITT Alphabet #5 
H— IA5 character 2/11 
BEL—IA5 character 0/7 
SYN—IA5 character 1/6 
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and dial-out access, backup for leased line connections, 
long-distance access to the network, and teletex. 

Datagram was deleted in 1984, while the following 
packet-level services were made available as options: 

• Registered Private Operating Agent (RPOA) Selection per¬ 
mits the use of one or more networks to route a call to its 
destination. If the user selects only one network, either 
the basic or extended format of the RPOA Selection can 
be used; if more than one network is chosen, the ex¬ 
tended format is used. 

• Call Redirection permits the rerouting of calls if the first 
tried route fails. 

• Call Redirection Notification informs the recipient of the 
forwarded call that the call has been redirected. 

• Called Line Address Modified Notification tells the caller, 
within a call confirmation packet, that the call has been 
redirected. 

• Hunt Group distributes incoming calls that have an ad¬ 
dress associated with the hunt group. 

• Charging Information gives the caller information on 
time and charges and requires a new field in the call¬ 
clearing packet format. 

• Local Charging Prevention is a security facility that pre¬ 
vents reverse or third-party call charges. 

• Network User Identification accommodates user ID, bill¬ 
ing, and on-line facilities registration. This permits users 
to communicate directly with the packet data network to 
change the parameters of their subscriptions. 

The packet level is an octet-oriented (eight bits per octet) 
structure. Packet sizes can vary from 1,024 to 2,048 octets, 
but only within a network. Network-to-network exchange 
is limited to 128 octets. Closed user group facilities can 
accommodate very large private-packet networks, al¬ 
though the number of closed user groups to which a DTE 
can belong is network dependent. 

Link-level changes implemented in 1984 created a clear 
separation between the Link Access Procedure (LAP) and 
the Link Access Procedure Balanced (LAPB). Multilink 
procedures for a single interface were also implemented. 
LAPB underwent an alignment with the single-link proce¬ 
dure of X.75. An extended numbering option (modulo 
128) was added to LAPB to enable the sequencing of 127 
frames and the use of satellite facilities. In addition, the 
1984 revisions to X.25 refined the procedure for the imple¬ 
mentation of the D-bit, polished technical accuracy, and 
defined the rules for new fields and formats. 

X.25 Communications 

X.25 is titled Interface Between Data Terminal Equipment 
(DTE) and Data Circuit-Terminating Equipment (DCE) 
for Terminals Operating in the Packet Mode on Public Data 
Networks. It provides a precise set of procedures for com¬ 
munications between DTE and DCE for terminal equip¬ 
ment operating in a packet environment. The DCE in this 
case is a node processor that serves as an entry/exit point 
on the packet network side of the user/network interface. 

The Data Terminal Equipment (DTE) is a programma¬ 
ble device on the user side of the user/network interface. 
The DTE is located at the user site when the on-site equip¬ 
ment supports X.25; at such installations, the DTE can be 
either a computer, a front-end processor, or an intelligent 
terminal, as shown in Figure 2. The DTE can be a group of 


intelligent terminals (multiplexed to avoid the use of mul¬ 
tiple lines) that transmit data over the packet network to a 
remotely located host. It can also be a processor acting on 
calls received from multiple locations that communicate 
over the packet network. 

Regardless of the device or application, all DTEs 
present standard formatted data and control information 
to the DCE over standard communications facilities. De¬ 
vices operate over the network in the virtual circuit mode. 
Essentially, the user causes the network to establish a logi¬ 
cal circuit connection with the receiving station for the 
transmission of multiple contiguous packets. (The actual 
physical circuit over which individual packets are trans¬ 
mitted can vary during a session, but the logical circuit 
ensures presentation of each packet to the receiving station 
in the proper order.) Information delivery is so rapid that 
the user appears to have an end-to-end, dedicated channel. 

Users who do not support X.25 can access the public 
data network for packet data transmission; however, they 
cannot transmit directly to a DCE or network node. They 
must transmit to a special network-operated PAD, dis¬ 
cussed earlier in this report. Terminal transmissions are 
stored in a buffer at the PAD. There they are assembled 
into packets and sent to the device at the other end of the 
virtual circuit. Packets arriving at the PAD from the net¬ 
work are reassembled into the appropriate format before 
they are sent on to the terminal. The PAD is programmed 
and configured to interface properly with the protocol and 
physical characteristics of the user’s device. Data pre¬ 
sented to the PAD is reformatted into X.25 format and 
forwarded to the DCE. 

Recommendation X.25 is divided into those specifica¬ 
tions required for a device or network to comply and those 
that are optional. Approximately one third are required; 
the remaining two thirds of the specifications are optional. 

The excess throughput capacity inherent in the X.25 
standard allows for future network growth and technologi¬ 
cal progress. For example, a single X.25 interface can the¬ 
oretically handle 4,095 virtual channels, packet sizes up to 
2048 bytes each, and packet sequencing up to 128 packets 
per logical channel. Most network suppliers’ nodal proces¬ 
sors are too small to handle this much traffic through a 
single interface. Therefore, in practice, the support offered 
over each interface is limited to the current capacity of the 
network’s access node. 

Functional Layers 

Recommendation X.25 defines three functional layers: the 
Physical Layer (Level 1), the Link Layer (Level 2), and the 
Packet Layer (Level 3). These are consistent with the first 
three layers of the ISO Reference Model for Open Systems 
Interconnection (OSI). (Although OSI labels its third layer 
the Network Layer, its function parallels that of the Packet 
Layer. Both provide the means to establish, maintain, and 
terminate connections.) 

Level 1: Physical Level —outlines the physical, func¬ 
tional, and electrical characteristics of the DTE/DCE in¬ 
terface. X.21 uses the transmission of coded character 
strings across a 15-pin connector to define standard inter¬ 
face functions, e.g., Transmit Data. Its specifications are 
defined in CCITT Recommendation X.21. 

Although X.21 is the recommended physical-level in¬ 
terface for X.25, the availability of data communications 
equipment with X.21 capabilities is limited, especially in 
the United States. As a result, the CCITT has accepted an 
interim recommendation, X.21 bis, as the X.25 physical 


© 1992 McGraw-Hill, Incorporated. Reproduction Prohibited. 
Datapro Information Services Group. Delran NJ 08075 USA 


AUGUST 1992 



12 


2720 

Standards 


CCITT Packet Switched 
Networking Standards 
X Series 


Data Networking 


Figure 2 . 

A Sample User Terminal Configuration for Operating on a Public Data Network (PDN) in Packet Mode, with X.25 as the Interface to 
the Network 


User Location Public Packet-Switching Network 



# Signifies an interface that must conform to X.25 Level 2 Physical Interface Standards. 


interface. X.21 bis is functionally equivalent to EIA RS- 
232-C, which assigns a separate function to each pin across 
a 25-pin connector. 

Level 2: Link Level —describes the link access proce¬ 
dures used for data interchange between a DCE and a 
DTE. In the CCITT Recommendation X.21, International 
User Classes of Service in Public Data Networks , X.25 spec¬ 
ifies that the DTE and DCE must operate in the following 
user classes of service: class 8 (2400 bps), class 9 (4800 
bps), class 10 (9600 bps), or class 11 (48K bps). The proce¬ 
dure calls for a full-duplex facility so that the DTE and 
DCE can conduct two-way, simultaneous, independent 
transmissions. The procedures use the principles and ter¬ 
minology of the High-level Data Link Control (HDLC) 
protocol specified by the International Organization for 
Standardization. 

Level 2 comprises three procedures: the Link Access 
Procedure (LAP), the Link Access Procedure Balanced 
(LAPB), and the Multilink Procedure (MLP). The original 
X.25 data link control procedure embraced LAP, which is 
similar to the HDLC Asynchronous Response Mode 


(ARM). Due to some incompatibilities with some ele¬ 
ments of procedures, Level 2 of the X.25 Recommenda¬ 
tion was revised to incorporate LAPB. Similar to the Asyn¬ 
chronous Balanced Mode (ABM) of HDLC, it provides for 
a “balanced” configuration; that is, each side of the link 
consists of a combined primary/secondary station. The 
Multilink Procedure is used for data transmission on one 
or more single links. Each link conforms to the X.25-de- 
fined frame structure and to the elements of procedure de¬ 
scribed in LAPB. 

Software in both DTE and DCE performs Level 2 pro¬ 
cessing. This software appends control information onto 
packets that are ready for transmission, maintains control 
of the transmissions, performs transmission error check¬ 
ing, and strips a successfully received frame down to a 
packet. The packet consists of packet control information 
and (optionally) user data; packets are discussed in detail 
later in this report. 

HDLC specifies certain control fields that must be ap¬ 
pended to both ends of a packet, resulting in a transmis¬ 
sion format called a frame . Appended in front of a packet 
are a beginning Flag field, an Address field, and a Control 
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Figure 3. 

Frame Formats for Packet Mode Transmission 



■Frame* 


\ 


Fields Generated by: 
Application Program 
Level 3 Software 
Level 2 Software 



- Packet -► 


Flag 

Address 

Control 

Field 

Packet 

Control 

Infomation 

User Data 

Field 

Sequence 

Check 

Flag 

1 - 

1 

i— 

! 

1 

1 


L. . . 1 i 

I 

i 


Description 

Value is 01111110. 

Value for DTE to DCE command frame is "10000000". 
Value for DTE to DCE response frame is "11000000". 


Field 


Flag 

Address 


Size, 

bits 


Value for DCE to DTE command frame is "11000000". 
Value for DCE to DTE response frame is "10000000". 


Control 


8 I Frame: 

Bit 1 is "0". 

Bits 2, 3, 4, are N(S) (transmitter send sequence count). 
Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receive sequence count). 


Packet 24 

Control 1,024 

User Data 

16 

Field Sequence 
Check 

8 

Flag 


S Frame: 

Bit 1 is *T. 

Bit 2 is "0". 

Bits 3, 4 identify Supervisory Command. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receiver sequence count). 

U Frame: 

Bit 1 is 1. 

Bit 2 is 1. 

Bits 3, 4 are first part of Unnumbered Frame Command identifier. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are second part of Unnumbered Frame Command identifier. 
Control information. 

1,024 data bits are normal maximum; exceptional maximum is 2,040 data bits. 
Check bits for user data. 


Value is "01111110". 


field. Appended behind the packet are a Frame Check Se¬ 
quence field and a closing Flag field. Figure 3 gives the size 
and description of each field. The receiving device uses the 
two Flag fields to ascertain the beginning and ending of a 
frame. A single Flag field can be used as the closing flag for 
one frame and the opening flag of the next frame. The Ad - 
dress field, under HDLC, is used to identify the station(s) 


for which the command is intended in command frames or 
to identify the station sending the response in response 
frames. 

The Control field identifies the type of frame and sup¬ 
plies control information pertinent to that type of frame. A 
frame can be either an Information Frame (I-Frame), a Su¬ 
pervisory Frame (S-Frame), or an Unnumbered Frame (U- 
Frame). See Table 5 for the encoding of this field. 
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Figure 4. 

X.25 User and Network Software Relationships 


... 

Communications 

Public Packet- 


Facility 

Switching Network 


DCE 



Physical Interface 


An Information Frame contains a user packet. The 
Control field of the I-Frame contains the N(S) transmitter 
Send Sequence Count, the N(R) transmitter Receive Se¬ 
quence Count, and the Poll/Final (P/F) bit. N(S) is the se¬ 
quence number of this frame sent from this transmitter to 
this receiver. N(R) is the sequence number of the next 
frame this transmitter expects to get from the receiver 
when the receiver becomes a transmitter. The Poll/Final 
bit indicates whether a transmission acknowledgment is 
required or when the final frame in a stream has been 
transmitted. 

The Supervisory Frame transmits one of three supervi¬ 
sory commands and cannot contain user data. The Control 
field of the S-Frame contains the command, the P/F bit, 
and an N(R). Table 6 summarizes the commands and re¬ 
sponses possible in the Control field. 

The Unnumbered Frame extends the number of link 
control functions, without incrementing the sequence 
counts at either the sending or receiving station. 

A U-Frame control field contains the Unnumbered 
command and the P/F bit. One of the U-Frame commands 
initializes the DTE/DCE network to the Asynchronous Re¬ 
sponse Mode (ARM) of operation, which permits both 
DTE and DCE to initiate transmission to each other. 

The Frame Check Sequence (FCS) field contains a 16- 
bit check pattern created at framing time by generating 
check bits based upon the binary value of the data in the 
packet. The receiving device performs the same calcula¬ 
tion and compares its results with the value that the send¬ 
ing device had placed in the FCS field. If these values do 
not agree, the frame has a transmission error and is dis¬ 
carded. Discarding causes the receiving device to send an 
S-Frame with the Reject Recovery command. This 
S-Frame contains the frame numbered N(R), thus ac¬ 
knowledging receipt of all frames numbered N(R)-1 and 
below, and initiates retransmission of frames N(R) and 
above. 

In effect, Level 2 envelops the packet in control infor¬ 
mation and prescribes procedures that ensure a high de¬ 
gree of transmission accuracy and detection of lost frames 
during transmission. 
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Level 3: Packet Level —describes the packet format and 
control procedures for the exchange of packets between the 
DTE and the DCE. In addition to the user data packet 
format, there are several formats for DTE/DCE adminis¬ 
trative messages. 

The software for formatting packets and controlling 
packet exchange is the Level 3 software resident in both 
the DTE and the DCE. Figure 4 shows the relationship of 
Level 3 and Level 2 software operating in the DTE and the 
DCE. In the DTE, a user application program normally 
presents the data to be transmitted to the operating sys¬ 
tem’s communications access method. The access method 
invokes Level 3 software to append the packet header in¬ 
formation, then invokes Level 2 software to create the 
frame. Packet header formats are discussed below. 

Once the frame is created, it is ready for transmission. 
Upon receiving the frame, the receiving DCE invokes 
Level 2 software to perform error detection and sequence 
checking and to strip the accepted frame down to a packet. 
The packet is presented to Level 3 software for packet- 
level processing and to prepare the packet for transmission 
to the destination DCE. The physical address of the desti¬ 
nation DTE, derived from the call initiation, is inserted 
into the packet during Level 3 processing. At the network 
destination DCE, Level 3 software reformats the packet 
control information and presents the resulting packet to 
Level 2 software; Level 2 software includes the packet in a 
frame for transmission to the destination DTE (user). At 
the destination DTE (user), Level 2 software performs er¬ 
ror detection and sequence checking and strips accepted 
frames down to the packet. Level 3 software is then applied 
to the packet to strip the header information from the 
packet and pass the user information to the appropriate 
application program via the communications access 
method. Table 7 summarizes the types of packets ex¬ 
changed between terminals. 

The Packet Header consists of three octets. In Octet 1, 
the first four bits represent the Logical Channel Group 
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Figure 5. 

X.25 Packet Header Format 


-Octet 1- % -Octet 2-K-Octet 3 


mum 

IHHIH 


1 2 3 415 6 7 8 

1 2 3 4 5 6 7 8 

1 2 3 4 5 6 7 8 

1 

Logical 1 General 
Channel 1 Format 

Logical Channel Number 

Packet Type Identifier 

Group i Identifier 
Number j 

i 




Number, and the final four bits represent the General For¬ 
mat Identifier. Octet 2 represents the Logical Channel 
Number, and Octet 3 represents the Packet Type Identi¬ 
fier. See Figure 5. 

The Logical Channel Group Number and the Logical 
Channel Number provide the routing information that di¬ 
rects the packet over one of the logical channels. The num¬ 
bering system for the logical channels is dynamic and re¬ 
fers to a switched data path within the packet network. 

The General Format Identifier indicates the general for¬ 
mat of the rest of the header. Specific bit patterns are es¬ 
tablished for the following: call setup packets; clearing, 
flow control, interrupt, reset, restart, and diagnostic pack¬ 
ets; and data packets. 

The Packet Type Identifier establishes the packet’s func¬ 
tion. Examples of functions include call setup, priorities, 
and data. If applicable, it may identify the packet’s place in 
sequence. See Table 7 for the various packet types. 

Packet-Level Procedures 

X.25 Level 3 defines procedures for call initiation, data 
transfer, interrupts, reset, restart, and clearing. Some of 
these procedures are summarized below. 

Call Initiation : The Level 3 software in a DTE initiates 
a transmission by sending a Call Request packet. This 
packet enables the calling DTE to request the opening of a 
logical channel. The calling DTE designates the channel 
number based upon the original assignments that were 
made when the user subscribed to the network. The Call 
Request packet also informs the network of the calling 
DTE’s address and of the called DTE’s address. Until the 
call is disconnected, the network retains the addresses of 
both devices associated with the logical channel number. 
Therefore, each data packet that is transmitted needs to 
contain only the logical channel number. The network ap¬ 
pends the destination address just before routing the 
packet. At the time the Call Request is issued, the logical 
channel indicated by the calling DTE must be in a Ready 
state, that is, not being used to handle another call. Upon 
receipt of the Call Request by the called DTE, the specified 
logical channel is designated as being in the DTE Waiting 
state. The packet is then transmitted to the destination 
DCE. 


The destination DCE transmits an Incoming Call 
packet to the originating DTE and places the logical chan¬ 
nel in the DCE Waiting state. 

The called DTE indicates its willingness to accept the 
call by transmitting a Call Accepted packet across the 
DTE/DCE interface. The Call Accepted packet specifies 
the same logical channel that is indicated by the Incoming 
Call packet. This places the specified logical channel in the 
Data Transfer state. (The logical channel at the calling 
DCE is still in the Wait state.) 

A Call Connected packet is then sent by the DCE to the 
calling DTE and sets the logical channel status to the Data 
Transfer state; the logical channel is then ready for transfer 
of data packets. This applies only for virtual circuit con¬ 
nections; for permanent virtual circuit connections, the as¬ 
signed logical channels are always in the Data Transfer 
state. 

It is possible for a DCE to receive a Call Request (from 
a DTE) and an Incoming Call (from the network) simulta¬ 
neously, with both messages specifying the same logical 
channel. This is called a call collision; when a collision oc¬ 
curs, the DCE cancels the Incoming Call and proceeds to 
process the Call Request. 

Data Transfer. Once the logical channel is in the Data 
Transfer state, data, flow control, or reset information 
packets can be transmitted. 

The Data packet format includes the packet send and 
receive sequence numbers. The calling DTE can transmit 
up to a predetermined number of packets before requiring 
a response. This number is referred to as the window. All 
packet networks must accommodate a lower window edge 
of at least eight, permitting at least seven packets to be 
outstanding before an acknowledgment is required. The 
upper window value (the maximum number of outstand¬ 
ing packets) may not exceed 127 (modulo 128). 

Upon receipt of an authorized packet, the receiving de¬ 
vice can either authorize additional transmission by trans¬ 
mitting a Receive Ready packet to the sending device or 
deny authorization to transmit by issuing a Receive Not 
Ready packet. 

When transmitting Data packets, the Interrupt packet 
can bypass flow control (authorization procedures). A 
DTE can transmit an Interrupt packet to another DTE. To 
avoid swamping the receiver with Interrupt packets, the 
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Figure 6. 

Basic System Structure of XJ5 Signaling and Data Transfer Procedures 


r 



Link 

A1 orGI 


sender cannot send a second Interrupt packet until the first 
Interrupt packet is acknowledged by an Interrupt Confir¬ 
mation packet. 

While Data packets or Interrupt packets are being 
transmitted, issuing a Reset Request packet can reset the 
call. A DCE initiates a reset by issuing a Reset Indication 
packet. In either case, the logical channel is placed in the 
Data Transfer state. Any Data, Interrupt, Receive Ready 
(RR), or Receive Not Ready (RNR) packets in the network 
at the time of reset are ignored. If a DTE and DCE trans¬ 
mit Reset packets simultaneously, a reset collision occurs. 
The net effect is to place the logical channel in the Data 
Transfer state, ready for Data and Interrupt packets. 

A DTE or a DCE initiates a request for clearing (discon¬ 
necting) a logical channel. Upon confirmation by the other 
device, the logical channel is placed in the Ready state. 

Error Handling (Packet Level): When an error occurs, 
the DCE transmits Reset, Clear, and Restart indication 
packets to the DTE. Reset reinitializes a virtual call or per¬ 
manent virtual circuit. Reset removes all Data and Inter¬ 
rupt packets on the logical channel and resets the lower 
window edge to zero. It affects only one logical channel 
number (one user). Reset procedures, which apply only in 
the Data Transfer state, handle specific error events, such 
as local procedure error, remote procedure error, network 
congestion, incompatible destination, network out of or¬ 
der, etc. Clear affects only one logical channel number (one 
user). It clears a session when, for example, the host or host 
link crashes. In this case, the network initiates Clear proce¬ 
dures on the terminal link. It effectively logs off the termi¬ 
nal user. Clear resets the lower window edge to 0. Restart 
affects all users (all logical channels on a given link) and 
clears all calls on that link. Restart is used when a failed 
link returns to service; it makes sure that all calls were 
cleared when the link went down. Restart also is used when 
either side (DTE or DCE) reports error conditions at the 
packet level; the good side initiates the restart procedures. 

In some networks, a diagnostic packet indicates unusual 
error conditions. A diagnostic packet from the DCE pro¬ 
vides information on events that are considered unrecov¬ 
erable at the packet level; the information permits the 
DTE to analyze and initiate recovery by higher levels. No 
confirmation is required on receipt of a diagnostic packet. 
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Implementation Considerations for Users 

X.25 recognizes that DTEs differ in their degree of sophis¬ 
tication. A simple DTE may have fixed packet formats and 
built-in parameter values, while a sophisticated DTE may 
work with varying packet formats and provide variable pa¬ 
rameters to take advantage of the many network functions 
and signaling capabilities offered. 

At the physical level, the transmission rate DTE uses to 
access an X.25 network should be governed by the 
throughput and response time requirements of the user. 


Table 4. X.21 Pin Assignments 


Pin 

Number 

Employing 

X.26 

Employing 

X.27 

1 

See Note (3) 

See Note (3) 

9 

Ga 

T(B) 

2 

T 

T(A) 

10 

Ga 

C(B) 

3 

C 

C(A) 

11 

R(B) 

R(B) 

4 

R(A) 

R(A) 

12 

1(B) 

KB) 

5 

1(A) 

1(A) 

13 

S(B) 

S(B) 

6 

S(A) 

S(A) 

14 

m 

B(B) 

7 

B(A) 

B(A) 

15 

Reserved for 
future use 

Reserved for 
future use 

8 

G 

G 

Notes: 


(1) X.21 pin assignments are defined by ISO 4903-1980. 

(2) Where balanced ciruits are, the associated pairs are desig¬ 
nated “A” and "B.” 

(3) Pin 1 is reserved for connection of the shield or shielded in¬ 
terconnecting cable. 
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Table 5. X.25 Level 2 Commands and Responses 


Commands (1) Responses Encoding of Control Field 


Format 





1 

2 

3 

4 

5 

6 

7 8 

Information 

1 

(information) 



0 

1 — n(SH 

P 

1— n(R)_i 

transfer 












Supervisory 

RR (3) 

(receive ready) 

RNR 

(receive not ready) 

1 

0 

0 

0 

P/F 


N(R) 


RNR (3) 

(receive not ready) 

RNR 

(receive not ready) 

1 

0 

1 

0 

P/F 


N(R) 


REJ (3) 

(reject) 

REJ 

(reject) 

1 

0 

0 

1 

P/F 


N(R) 

Unnumbered 

SARM 

(set asynchronous 

DM 

(disconnected 









(2,3) 

response mode) 

(2) 

mode) 

1 

1 

1 

1 

P/F 

0 

0 0 


SABM 

(set asynchronous 











(2) 

balanced mode) 



1 

1 

1 

1 

P 

1 

0 0 


DISC 

(disconnect) 



1 

1 

0 

0 

P 

0 

1 0 




UA 

(unnumbered 












acknowledgment) 

1 

1 

0 

0 

F 

1 

1 0 




CMDR 

(command reject) 

1 

1 

1 

0 

F 

0 

0 1 




FRMR 

(frame reject) 









(1) The need for, and use of, additional commands and responses are for further study. 

(2) DTEs do not have to implement both SARM and SABM; furthermore, DM and SABM need to be used if SARM only is used. 

(3) RR, RNR, and REJ supervisory command frames are not used by the DCE when SARM is used (LAP). 


Factors to consider include the maximum number of vir¬ 
tual circuits operating simultaneously and traffic charac¬ 
teristics of throughput-critical and response-time-critical 
virtual circuits. 

At the link level, Link Access Procedures (LAPs) and 
Link Access Procedures Balanced (LAPBs) are defined. A 
DTE might implement only LAPB. Parameters that are 
part of the LAPB procedures can be set to constants for all 
network connections. For example, a timer (Tl) may be set 
according to the slowest required line speed; a constant 
such as three seconds may be used. Also, the maximum 
permitted number of unacknowledged I-Frames (informa¬ 
tion frames) may be determined. The network provider 
must agree to this. All networks support a window of at 
least seven I-Frames. The maximum packet size (number 
of bits) of the I-Frame must also be established. 

If the DTE handles certain character sizes (octets), the 
frame level should be capable of accommodating any num¬ 
ber of bits correctly (generate acknowledgment, calculate 
frame check sequence). How such a properly received 
frame is processed depends on the individual system and 
may include actions such as discarding the frame, padding 
it, clearing the call, or resetting. 


Connections Between Packet Switched 
Data Networks 

CCITT Recommendation X.75 describes the procedures 
for the interconnection of packet switched networks. 
Many public packet switched data networks support X.75 
procedures, including AT&T Accunet, TransCanada’s 
Datapac, Graphnet Freedom Network II, US Sprint’s 
SprintNet, and WangPac networks. 

X.75 is similar to X.25 in that it specifies procedures 
for the physical, link, and packet levels. Signal Terminal 
Equipment (STE), which acts as a bridge node between 
networks, implements X.75 procedures. A related stan¬ 
dard, CCITT X.121, defines the international numbering 
plan for public data networks. 


Recommendation X.75 

Recommendation X.75, Terminal and Transmit Call Con¬ 
trol Procedures and Data Transfer System on International 
Circuits Between Packet-Switched Data Networks , pro¬ 
vides the rules for transmitting data between different data 
networks. The basic system structure is made up of com¬ 
municating elements that function independently. These 
elements include the physical circuits, which comprise 
links A1 or G1 (as defined in X.92), and a set of mechani¬ 
cal, electrical, functional, and procedural interface charac¬ 
teristics; packet transfer procedures, which operate over 
the physical circuits and provide for the transport of pack¬ 
ets between STEs; and packet signaling procedures, which 
use the packet data transfer procedures and provide for the 
exchange of call control information and user traffic be¬ 
tween STEs. Figure 6 shows the basic system structure of 
the signaling and data transfer procedures. The interna¬ 
tional link is assumed to be data link A1 and/or data link 
G1 as defined in Recommendation X.92. The interna¬ 
tional link should be capable of supporting full-duplex op¬ 
eration. 

Link-level packet transfer procedures between STEs 
consist of the Single Link Procedure (SLP) and the Multi¬ 
link Procedure (MLP). The SLP is used for data inter¬ 
change over a single physical circuit between two STEs. 
When multiple physical circuits are used in parallel, the 
SLP is used independently on each circuit. The MLP is 
used for data interchange over multiple parallel links. The 
MLP may be used over a single link when the communicat¬ 
ing parties agree to this procedure. Transmissions are full 
duplex. SLP is based upon the Link Access Procedure Bal¬ 
anced (LAPB) as described in X.25 and uses the principle 
and terminology of the International Organization for 
Standardization’s (ISO’s) High-level Data Link Control 
(HDLC). For SLP, either modulo 8 (nonextended mode) 
or the modulo 128 (extended mode) may be used. The 
MLP is based on the multilink procedures specified by the 
ISO and performs the functions of distributing packets 
across available SLPs. 

Three channel states are defined: the link channel state, 
which provides transmission in one direction; the active 
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Table 6. Summary of Packets Exchanged Between Terminals During a Virtual Call 


Events 

Activity at Calling DTE 

Activity at Called DTE 

Call Initiation 

Call Request packet is sent 

Call Connected packet is received 

incoming Call packet is received 

Call Accepted packet is sent 

Data Transfer 

Data packet sent 

Data packet received 

Ready Receive packet sent 


Ready Receive packet received 

Data packet B sent* 


Data packet A sent* 

Data packet B received* 

Data packet A received* 

Disconnect 

Clear Request packet sent 

Clear Confirmation packet received 

Clear Indication packet received 

Clear Confirmation packet sent 


* Two-way (full-duplex) transmission of data packets between terminal equipment. 


channel state, which means that the incoming or outgoing 
channel is receiving or transmitting a frame; and the idle 
channel state, which means that the incoming or outgoing 
channel is receiving or transmitting at least 15 contiguous 
1 bits. 

Data is transmitted in frames. Each frame must contain 
an Opening Flag (8 bits), an Address field (8 bits), a Con¬ 
trol field (8 bits), a Frame Check Sequence (FCS) field (16 
bits), and a Closing Flag (8 bits). An Information field of 
an unspecified number of bits, which follows the Control 
field, is optional. 

The Control field contains a command or response, and 
sequence numbers if applicable. Control field formats may 
be one of three types: numbered information transfer (I 
format), numbered supervisory functions (S format), and 
unnumbered control functions (U format). The I format 
performs information transfer functions. The S format 
performs link supervisory control functions, such as ac¬ 
knowledging I frames, requesting transmission of I frames, 
and requesting a temporary suspension of transmission of 
I frames. The U format provides additional link control 
functions. 

Each I frame is numbered sequentially. The send state 
variable V(S) represents the sequence number of the next 
in-sequence I frame to be transmitted. The value of the 
V(S) is incremented by one with each successive I frame 
transmission but cannot exceed N(R) of the last received I 
or S format frame by more than the maximum number of 
outstanding frames. The send sequence number N(S), con¬ 
tained only in I frames, is set equal to the value of V(S). 
The receive state variable V(R) represents the sequence 
number of the next in-sequence I frame expected to be re¬ 
ceived. The value of V(R) is incremented by one when an 
error-free, in-sequence I frame whose N(S) equals V(R) is 
received. Both I frames and S frames contain the receive 
sequence number N(R). N(R) is the expected send se¬ 
quence number of the next received I frame. When the 
STE transmits N(R), it indicates that all I frames num¬ 
bered up to and including N(R)-1 have been received cor¬ 
rectly. 

All frames contain the Poll/Final (P/F) bit, which is re¬ 
ferred to as the P bit in command frames and the F bit in 
response frames. The STE solicits a response from another 
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STE by setting the P bit to 1; the answering STE responds 
by setting the F bit to 1. The following commands and re¬ 
sponses are supported: 

• Information (I) command —transfers sequentially num¬ 
bered frames that contain an information field; 

• Receive ready (RR) command and response —used by the 
STE to indicate that it is ready to receive an I frame or to 
acknowledge a previously received I frame; 

• Receive not ready (RNR) command and response —used by 
the STE to indicate a busy condition; 

• Reject (REJ) command and response —used by the STE to 
request retransmission of I frames beginning with frame 
numbered N(R); 

• Set asynchronous balanced mode (SABM) command —an 
unnumbered command used to set the addressed STE in 
the asynchronous balanced mode information transfer 
phase; all command/response control fields are one octet 
(eight bits); 

• Set asynchronous balanced mode extended (SABME) com¬ 
mand —an unnumbered command used to set the ad¬ 
dressed STE in the asynchronous balanced mode infor¬ 
mation transfer phase; all numbered command/response 
control fields are two octets; all unnumbered command/ 
response control fields are one octet; 

• Disconnect (DISC) command —terminates the previ¬ 
ously set mode; DISC indicates that the STE transmit¬ 
ting DISC is suspending operation; 

• Unnumbered acknowledge (UA) response —used by the 
STE to acknowledge mode-setting commands; 

• Disconnected mode (DM) response —reports STE status 
when it is logically disconnected from the link and is in 
the disconnected phase; and 

• Frame reject (FRMR) response —indicates an error condi¬ 
tion that is not recoverable by retransmission of the 
frame. 

Packet-level signaling procedures relate to the transfer of 
packets at the STE-X/STE-Y (X/Y) interface. Recommen¬ 
dation X.75 specifies signaling procedures for virtual call 
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Table 7. Packet Types and Their Use in Various Functions 


Packet Type Service 


Function 

From DCE to DTE 

From DTE to DCE 

Switched 

Virtual 

Circuit 

Perm. 

Virtual 

Circuit 

Call Setup and Cleaning 

In Incoming Call 

Call Request 

X 



Call Connected 

Call Accepted 

X 



Clear Indication 

Clear Request 

X 



DCE Clear 

DTE Clear 




Confirmation 

Confirmation 

X 


Data and Interrupt 

DCE Data 

DTE Data 

X 

X 


DCE Interrupt 

DTE Interrupt 

X 

X 


DCE Interrupt 

DTE Interrupt 




Confirmation 

Confirmation 

X 

X 

Flow Control and Reset 

DCE RR (Receive 

DTE RR 

X 

X 


Ready) 

DTE RNR 

X 

X 


DCE RNR (Receive 

DTE REJ* 

X 

X 


Not Ready) 

Reset Request 

X 

X 


Reset Indication 

DTE Reset 




DCE Reset 

Confirmation 

X 

X 


Confirmation 




Restart 

Restart Indication 

Restart Request 

X 

X 


DCE Restart 

DTE Restart 




Confirmation 

Confirmation 

X 

X 

Diagnostics 

Diagnostics 


X 

X 


setup and clearing, for permanent virtual circuit service, 
for data and interrupt transfer, for flow control, and for 
reset. 

Logical channels are used to complete simultaneous vir¬ 
tual calls and/or permanent virtual circuits. A logical chan¬ 
nel group number and a logical channel number (in the 
range 0 to 15 inclusive and 0 to 255 inclusive, respectively) 
are assigned to each virtual call and permanent virtual cir¬ 
cuit. The logical channel group number and the logical 
channel number are contained in each packet type, except 
restart packets. 

The procedures for virtual call setup and clearing are 
used only when a logical channel is in the packet-level 
ready (RL) state. If call setup is possible, and no call or call 
attempt exists, the logical channel is in the ready (PL) state 
(within the RL state). Call setup is initiated when the STE 
sends a call request packet across the X/Y interface. The 
call request packet specifies a logical channel in the PL 
state. The logical channel is then placed in the call request 
state. The called STE indicates acceptance by the called 
DTE by sending a call connected packet across the X/Y 
interface. It specifies the same logical channel as that re¬ 
quested by the call request packet. The logical channel is 
then placed in the flow control ready (DL) state within the 
data transfer (P4) state. 

A logical channel (in any state) can be cleared when the 
STE sends a clear request packet, which specifies the logi¬ 
cal channel, across the X/Y interface. Upon receipt of a 
clear request packet, STE-X or STE-Y frees the logical 
channel and transmits a clear confirmation packet that 
specifies the same channel. This places the logical channel 
in the ready state within the RL state. Permanent virtual 
circuits require no call setup or clearing. 

Data transfer procedures apply independently to each 
logical channel at the X/Y interface. In the data transfer 
(P4) state, data, interrupt, flow control , and reset packets 
may be sent and received by the STE. The data transfer 


state exists within the packet-level ready state of a logical 
channel. Each data packet contains a sequence number 
called the packet send sequence number P(S); only data 
packets contain the P(S). 

The procedures for flow control and reset apply only in 
the data transfer state. Flow control applies to data pack¬ 
ets. A window is defined for each direction of transmission 
at the X/Y interface. The lowest number in the window is 
called the lower window edge. The maximum window edge 
does not exceed modulo 8 or 128, is unique to each logical 
channel, and is reserved for a period of time. For a partic¬ 
ular call, two window sizes, one for each direction of trans¬ 
mission, may be selected. The packet receive sequence 
number P(R) (modulo 8 or 128) conveys information from 
the receiver for the transmission of data packets. The P(R) 
becomes the lower window edge when transmitted across 
the X/Y interface, thereby authorizing additional data 
packets to cross the X/Y interface. 

Reset procedures are used to reinitialize a single call 
and apply only in the data transfer state. The STE sends a 
reset request packet that specifies the logical channel to in¬ 
dicate a request for reset. The logical channel is placed in 
the reset request state. The requested STE confirms by 
sending a reset confirmation packet, which places the logi¬ 
cal channel in the flow control ready state. 

Restart procedures are used to clear all calls simulta¬ 
neously. When the STE sends a restart request packet, the 
X/Y interface for each logical channel is placed in the re¬ 
start request state. In this state all packets, except restart 
request and restart confirmation packets, are discarded by 
the X/Y interface. An STE confirms by sending a restart 
confirmation packet, which places all channels in the ready 
state. 

Packet formats are based on the general structure of 
packets as defined in X.25. 
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Trends in Packet Switching 

X.25 packet switching is widely supported in existing data 
processing and data communications equipment. All ma¬ 
jor host computer and communications processor ven¬ 
dors, for example, have incorporated X.25 interfaces into 
their products. This is part of an overall trend in accepting 
international standards and the increasing availability of 
products conforming to these standards. 

The CCITT published revisions to the X Series stan¬ 
dards in 1984 and in 1989. Since that time, the ratification 
and publication of revisions has become a continuous, on¬ 
going process. Since the major building blocks for X.25 
were laid by 1984, all subsequent changes have been, and 
will continue to be, relatively minor. Some post-1984 
changes have revolved around efforts to make CCITT X 
Series standards compatible with those of the Interna¬ 
tional Organization for Standardization (ISO). Currently, 
discussions on how to provide greater interoperability be¬ 
tween various X.25 networks is taking place. Major devel¬ 
opments in packet switching today, however, center not 
around X.25, but around the development of new ISDN- 
related technologies, such as frame relay and Broadband 
ISDN, which provide much higher throughput through 
simplified packetization and routing schemes. This section 
discusses post-1984 changes to X.25 and its relationship to 
ISDN. 

Major Changes in 1988 Revisions 

In the 1988 revised standards, there were no changes at the 
physical and link levels. At the packet level, however, a 
new facility for redirecting calls, Call Deflection , was estab¬ 
lished. In 1984, the CCITT had made available a new Call 
Redirection facility, allowing the network to redirect all 
calls destined for a given address. This redirection could 
occur when the destination was out of order or busy, or it 
could be based on time of day or other criteria. The 1988 
facility extended this capability, allowing the destination 
subscriber to clear incoming calls to another party on a 
call-selective basis. The Clear Request packet contains the 
Call Deflection information that profiles the desired alter¬ 
nate party. 

Relationship Between CCITT and ISO Efforts 

CCITT X.25 packet-level protocol specifies a virtual cir¬ 
cuit service; the ISO has issued a compatible version of the 
packet standard, ISO 8208. In recent years, CCITT and 
ISO organizations have worked on standards to carry 
longer addresses in the DTE field to facilitate interworking 
with ISDN (E. 164). 

In 1988, the CCITT also modified the Address Exten¬ 
sion facilities to be consistent with ISO address length. 
Previously, a provisional 3 2-decimal/16-octet field had 
been recommended; this address length was increased to 
40 decimals/20 octets. The ISO also added these address 
recommendations to Addendum 2 of ISO 8348 (Connec¬ 
tion-Mode Network Service); the CCITT adoption is 
X.213. 

Connectionless Issues: Relationships With ISO Efforts 
At any layer of the Open Systems Interconnection (OSI) 
Reference Model, two basic forms of operation are possi¬ 
ble: connection oriented and connectionless. Connection- 
oriented service involves a connection establishment 
phase, a data transfer phase, and a connection termination 
phase. A logical connection is set up between end entities 
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prior to exchanging data. In a connectionless service, typi¬ 
cal of local area networks, each packet is independently 
routed to the destination. No connection establishment ac¬ 
tivities are required since each data unit is independent of 
the previous or subsequent one. Each transmission mode 
has a niche where it represents the best approach. For ex¬ 
ample, file transfers may benefit from a connection-ori¬ 
ented service, while point-of-sale inquiries may be best 
served by a connectionless service. 

Traditionally, the CCITT has pursued a connection- 
oriented philosophy, while ISO has shown interest in con¬ 
nectionless. While the original OSI standard, ISO 7498, is 
connection oriented, ISO saw the need to provide connec¬ 
tionless service by issuing an addendum to that protocol, 
ISO 7498/DAD 1. ISO has issued a standard for connec¬ 
tion-mode network service (ISO 8348), while the CCITT 
has issued an identical service, X.213. In regard to X.25 
itself, however, ISO has decided not to pursue the connec¬ 
tionless service, formerly known as “datagram” service. 
X.75 is also a connection-oriented service; ISO has shown 
considerable interest in a connectionless internetworking 
protocol (IP) and has developed the ISO 8473 to accom¬ 
modate it. 

Packet Switching in ISDN 

The goal of the Integrated Services Digital Network 
(ISDN) is to provide an end-to-end digital path over a set 
of standardized user interfaces, giving the user the capabil¬ 
ity to signal the network through an out-of-band channel. 
(In contrast, in X.25, the user signals the network in in- 
band fashion by issuing packets such as CALL REQUEST, 
CALL ACCEPTED, etc.) 

Currently, different types of interfaces to the telephone 
network exist for different services. These interfaces in¬ 
clude two-wire switched, two-wire dedicated, four-wire 
dedicated, DDS, and so forth. ISDN will provide a small 
set of interfaces that can be used for multiple applications. 
The CCITT has defined the following interfaces for ISDN: 

• 2B+D—two 64K bps channels and a 16K bps packet/ 
signaling channel (also called the Basic Rate Interface). 

• 23B+D—twenty-three 64K bps channels and a 64K bps 
packet/signaling channel (also called the Primary Rate 
Interface). 

• 3H0+D—three 384K bps channels and one 64K bps 
packet/signaling channel. 

• Hll—nonchannelized 1.536Mbps. 

• H12—nonchannelized 1.920Mbps. 

• Multislotted—multiples of 64K bps channels (up to 
1.536M bps) under the customer’s control. 

• Broadband—high data rates, based on an approach 
called synchronous optical network (SONET), building 
on multiplex of 51.84M bps. SONET standards negotia¬ 
tions began in 1986. The CCITT approved phase I of the 
standards in 1988 and phase II in 1989. This architecture 
has been called Broadband ISDN, in contrast to the 
other interfaces that have been considered part of Nar¬ 
rowband ISDN. 

With the exception of Broadband ISDN, all of the above 
interfaces could be carried on unloaded copper loops. Us¬ 
ing fiber has also been considered, as it would make the 
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local loop more robust. Out-of-band signaling makes pos¬ 
sible a new class of services. In addition, the 16K bps 
D-channel will be connected directly to the BOC’s packet 
switched network, providing the subscriber with the data 
multiplexing advantages packet switching offers. A major 
effort is under way in Europe to bring the system to mar¬ 
ket. In the United States, several trials have been under¬ 
taken, and limited ISDN service is already available. 

CCITT ISDN Standards 

ISDN provides a specific protocol that users can employ to 
signal the network. Currently, a three-layer protocol suite 
is defined. At the Basic Rate, the Physical Layer manages a 
192K bps, full-duplex bit stream using time-compression 
techniques and time division methods to recover the two 
B-channels and one D-channel. The remaining 48K bps 
stream is used for Physical Layer control information. The 
defined standards are 1.420 (Basic Rate Interface Defini¬ 
tion), 1.430 (Basic Rate Interface Layer 1), 1.421 (Primary 
Rate Interface Definition), and 1.431 (Primary Rate Inter¬ 
face Layer 1). 

The Data Link Layer is not defined for transparent 
B-channels used for circuit switched voice or data, but it is 
defined for the D-channel. For Narrowband ISDN, the 
D-channel employs a LAP-D Link Layer protocol, which is 
a subset of the ISO HDLC Data Link protocol, as specified 
in CCITT Recommendations Q.920 (1.440) and X.921 
(1.441). It provides statistical multiplexing for three chan¬ 
nel types: signaling information for the management of the 
B-channels; packet switched service over the D-channel; 
and optional channels, used for telemetry of other applica¬ 
tions. 

The Network Layer protocol for the signaling channel is 
specified in CCITT’s Q.930 (1.450) and Q.931 (1.451) 
specifications. It provides the mechanism for establishing 
and terminating connections on the B-channels and other 
network control functions. For the packet switched service 
over the D-channel, the Network Layer protocol is X.25. 
CCITT will define Layer 3 protocols for the optional chan¬ 
nels in the future, or they will be specified as national op¬ 
tions. 

A technique is required for specifying whether user-to- 
network signaling, user packet data, or user telemetry data 
is being sent over the D-channel. This technique involves 
the use of a service access point identifier (SAPI). 

Each layer in the OSI Reference Model communicates 
with the layers above and below it across an interface. The 
interface is through one or more service access points 
(SAPs). SAPs have a number of uses, including subad¬ 
dressing for internetworking situations, Transport Layer 
applications, and for user data packet service over an 
ISDN D-channel. 

Considering the applications to the Transport Layer, 
one should note that two general types of addressing in a 
communications architecture are available. Each host on 
the network must have a network address, allowing the 
network to deliver data to the proper computer. Each pro¬ 
cess within a host must have an address that is unique 
within the host; this allows the Transport Layer to deliver 
data to the proper process. These process addresses are 
identified using SAPs. A similar approach is followed for 
ISDN. 

LAP-D, the data link standard for ISDN, specifies the 
link access protocol used on the D-channel. LAP-D is 
based on LAP-B, which is based on HDLC. LAP-D must 
deal with two levels of multiplexing. First, at a subscriber 
location, multiple-user devices may be sharing the same 


physical interface. Second, each user device may support 
multiple types of traffic, including packet switched data 
and signaling. To accomplish this type of multiplexing, 
LAP-D employs a two-part address consisting of a termi¬ 
nal endpoint identifier (TEI) and a SAPI. Typically, each 
user terminal is given a distinguishing TEI. The SAPI iden¬ 
tifies the traffic type and the Data Link Layer services di¬ 
rected to Layer 3. For example, the SAPI value of 0 directs 
the frames to Layer 3 for call-control procedures; a SAPI 
value of 16 indicates a packet communication procedure. 
See Figure 7. 

Frame Relay 

Frame relay is a rapidly emerging, standards-based ad¬ 
dressing technique that has great potential in LAN/WAN 
networking and other interactive applications requiring 
high-throughput, low-delay transmission. Frame relay is 
based on the CCITT Layer 2 protocol developed for ISDN, 
Link Access Protocol D (LAPD). Unlike conventional 
X.25 packet switching, frame relay uses variable packet 
lengths and performs error checking only at the remote end 
of transmission. Any errors occurring between intermedi¬ 
ate network nodes are assumed caught and corrected by 
higher-layer protocols. Thus, intermediate nodes simply 
forward packets (called frames) without processing the 
datastream. In addition, frames must be received in the 
order in which they were sent, unlike some X.25 networks, 
which involves considerably less machine processing at the 
opposite end of transmission. These efficiencies result in 
superior performance, with data rates up to T1/El levels. 

Vendors from several different networking disciplines 
have established themselves as frame relay equipment pro¬ 
viders. These include traditional packet switched equip¬ 
ment suppliers such as Northern Telecom, US Sprint, 
BBN Communications, BT North America, Hughes Net¬ 
work Systems, and Netrix Corp.; T-carrier nodal processor 
vendors such as General DataComm, Newbridge Net¬ 
works, Network Equipment Technologies, StrataCom, and 
Timeplex; LAN internetworking (bridge and router) ven¬ 
dors; and communications carriers. 

Most commercial frame relay products are based on 
ISDN recommendations contained in the following Amer¬ 
ican National Standards Institute (ANSI) specifications: 

• T1.606: Frame Relaying Bearer Service—Architectural 
Framework and Service Description (T1S1/88-225) 

• Addendum to T1.606: Frame Relaying Bearer Service— 
Architectural Framework and Service Description 
(T IS 1/90-175) 

• T1.6ca: Core Aspects of Frame Protocol for Use with 
Frame Relay Bearer Service (T1S1/90-214) 

The CCIII has released frame-relay specification 1.122 , en¬ 
titled “Framework for Providing Additional Packet Mode 
Bearer Services.” Currently, only one packet service has 
been specified in ISDN standards: “Support of Packet 
Mode Terminal Equipment by an ISDN,” CCITT 1.462 
(X.31). 

Broadband ISDN and Cell Relay 

Broadband ISDN (BISDN) is the blueprint for public net¬ 
works in the mid-1990s (1994 and beyond). It is being de¬ 
veloped to support switched (on demand), semiperma¬ 
nent, and permanent broadband connections for both 
point-to-point and point-to-multipoint applications. 
Channels operating at 155M bps and 622M bps will be 
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Figure 7. 

SAPI Action for a Basic Rate D-Channel 


Signaling Packet Telemetry 



available under BISDN, allowing transmission of data, 
video, and digitized voice. 

Broadband services are aimed at both business applica¬ 
tions and residential subscribers. Connections will support 
both circuit mode and packet mode services of a single 
media, mixed-media, and multimedia. BISDN’s founda¬ 
tion is cell relay, and particularly the international stan¬ 
dard supporting it: Asynchronous Transfer Mode (ATM). 

Cell relay is a high-bandwidth, low-delay switching and 
multiplexing technology in which information is pack- 
etized into fixed-size slots called cells. A cell consists of an 
information field that is transported transparently by the 
network and a header containing routing information. 
With simplified protocols and cells with a fixed, short 
length (53 bytes), cell relay will make very high data rates 
possible. 

The CCITT has issued several Broadband ISDN speci¬ 
fications in its I-Series recommendations. 1.361, the 
BISDN ATM Layer Specification , defines the ATM cell 
structure and coding, including header formats and coding 
at both the User-Network Interface (UNI) and Network 
Node Interface (NNI). It also defines ATM protocol proce¬ 
dures. 1.311, entitled BISDN General Network Aspects, de¬ 
scribes networking techniques, signaling principles, traffic 
control, and resource management for BISDN. It defines 
ATM virtual section, virtual path, and virtual channel con¬ 
cepts. 

Off-the-shelf ATM products for BISDN are expected by 
1995; some ATM products are available already and a 
great deal of work continues world-wide. In 1990, Fujitsu 
announced a commercial BISDN switch. It switches 512 
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by 512 150M bps lines. Major trials are planned for 1992 
and beyond; a trial scheduled in Belgium in 1992 follows 
1991 trials in the U.S. and Japan. Several high-speed 
switching trials in the past two-to-three years have been 
undertaken in the U.S. and in Germany. NYNEX is plan¬ 
ning a trial in Boston while BellSouth plans one in North 
Carolina. MCI Communications Corp. plans an early de¬ 
ployment of Siemens Stromberg-Carlson ATM switches to 
provide broadband interLATA services in the U.S. These 
services are expected for the 1992-93 time frame. In late 
1991, Southern Bell Telephone installed what was hailed 
as the “first broadband ISDN switch in a U.S. CO.” The 
switch, which supports the 622M bps UNI, will be used by 
the University of North Carolina, as part of the VISTA- 
NET undertaking. 

A number of cell switch vendors have efforts underway 
to develop ATM-based equipment for frame relay applica¬ 
tions, rather than for mixed-media CO applications. It ap¬ 
pears that, in the U.S., the route to frame relay will be via 
cell relay switches; these support frame relay interfaces on 
the access side and cell relay on the backbone side. Exam¬ 
ples of this type of equipment include AT&T’s BNS-1000 
and BNS-2000, and Stratacom IPX products. StrataCom 
supports a 24-octet cell (with 4 octets of overhead); AT&T 
supports a 16-octet cell on the BNS-1000. Other early 
ATM equipment or service entrants include: Fujitsu Net¬ 
work Switching, ASCON Timeplex (TIMEPATH/Esprit), 
Network Equipment Technologies, Ungermann-Bass Inc., 
BBN (Emerald), and Siemens Stomberg-Carlson (Metro¬ 
politan Area Network Switching System). Several of these 
switches support both voice and data. ■ 
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In this report: Synopsis 

Packet Assembly/ Editor’s Note Report Highlights 

Disassembly . 3 In 1984, CCITT published Red A packet switched network permits a 

Books on wide-ranging topics, in- user’s data terminal equipment (i.e., 

X.21 Interface eluding the X.25 packet-switching a PC, host computer, or terminal) to 

Specifications . 7 standards. A set of revisions to the X communicate with the equipment of 

Series, the Blue Books, was pub- other geographically dispersed users. 

Recommendation lished in 1989. Since that time, stan- Data must be presented to the net- 

X.25 . 13 dards ratification and publication work in a prescribed manner, how- 

have been ongoing, continuous pro- ever. A packet assembler/ 
Connections between cesses. Each future addition or revi- disassembler (PAD), also referred to 

Packet Switched Data sion to the X Series standards will be as data circuit-terminating equip- 

Networks . 23 made available, as soon as they are ment (DTE), serves as a network 

finalized, in individual grey booklets. entry/exit point, packetizing and de- 

Trends in Packet Since the major building blocks of packetizing data according to the 

Switching . 25 the X standards were completed by rules specified by the X.3, X.28, 

1984, all post-1984 technical changes X.29, X.21, X.25, and X.75 recom¬ 
are relatively minor; they are dis- mendations of the CCITT. 

cussed in this report, however. 


Major developments in packet 
switching center around the develop¬ 
ment of ISDN-related technologies, 
such as fast packet switching and 
frame relay, which provide integra¬ 
tion of voice, video, and data, and 
support much higher throughput 
than traditional X.25 networks. IS¬ 
DN’s relationship with traditional 
X.25 packet switching is also dis¬ 
cussed. 


—By Martin Dintzis 
Assistant Editor 
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Analysis 


In the early days of packet switching, each Public 
Data Network (PDN) defined its own network ac¬ 
cess protocol, which permitted an appropriately 
equipped computer to communicate with other 


CCITT Packet Switched 
Networking Standards 
X Series 


devices on the network through a physical connec¬ 
tion to the PDN. Each of these protocols used a 
multiplexing technique that enabled a computer to 
establish and maintain one or more virtual circuits 
to other network communicating equipment. No 
industry standard for packet switching existed, 
however, and most computer manufacturers were 
reluctant to provide the necessary software to han¬ 
dle the variety of network access protocols. 

With the adoption of the X Series Recom¬ 
mendations by the CCITT in 1976. the PDNs 
could offer a standard network access protocol. 

The recommendations are continually fine-tuned. 


Table 1. CCIT Recommendations—X Series 


CCITT Description 

Recommendation 


X.1 

International user classes of service in 
public data networks: class 8 (2400 
bps); class 9 (4800 bps); class 10 
(9600 bps); or class 11 (48,000 bps) 

X.2 

International user facilities in public 
data networks 

X.3 

Packet assembly/disassembly (PAD) fa¬ 
cility in a public data network; lists op¬ 
tions and defaults for interactive 
asynchronous terminal connection to 
X.25 packet networks 

X.4 

General structure of signals of Interna¬ 
tional Alphabet No. 5 (IA5) code for 
data transmission over public data 
networks (IA5 is described in CCITT 
V.3) 

X.20 

Interface between data terminal equip¬ 
ment (DTE) and data circuit-terminat¬ 
ing equipment (DCE) for async 
transmission services on public data 
networks 

X.20 bis 

V.21-compatible interface between DTE 
and DCE for async transmission ser¬ 
vices on public data network 

X.21 

General-purpose interface between 

DTE and DCE for synchronous opera¬ 
tion on public data networks 

X.21 bis 

For use on public data networks by 

DTE that are designed to interface to 
synchronous V-Series modems 

X.24 

List of definitions of interchange circuits 
between DTE and DCE on public data 
networks 

X.25 

Interface between DTE and DCE for ter¬ 
minals operating in the packet mode 
on public data networks 

X.26 

Electrical characteristics for unbalanced 
double-current interchange circuits for 
data communications equipment 


CCITT 

Recommendation 

Description 

X.27 

Electrical characteristics for balanced 
double-current interchange circuits for 
data communications equipment 

X.28 

DTE/DCE interface for asynchronous 
device access to the PAD facility of a 
public data network in the same 
country 

X.29 

Procedure for the exchange of control 
information and user data between a 
packet mode DTE and a PAD facility 

X.32 

Procedure for communications between 
users and packet networks through 
the switched telephone network and 
through circuit switched public data 
networks 

X.75 

Expanded X.25 recommendation for in¬ 
ternetwork communications between 
packet switched networks; interface is 
defined between two STEs (Signaling 
Terminal Equipments) that are a part 
of ISDEs (International Data Switching 
Exchanges), with expanded support 
for wideband links, extended sequenc¬ 
ing, and an expanded network utility 
field for international call 
establishment 

X.92 

Hypothetical reference connections for 
public synchronous data networks 

X.95 

Network parameters in public data 
networks 

X.96 

Call progress signals in public data 
networks 

X.121 

International numbering scheme for 
multinetwork communications contain¬ 
ing a 4-digit DNIX (Data Network Iden¬ 
tification Code), 3-digit area code, 5- 
digit host identification, a 0- to 2-digit 
subaddress 
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Revised editions are published at four-year inter¬ 
vals; the 1989 draft incorporates the latest revi¬ 
sions and recommendations. The next published 
revision will be available in 1992. 

This report focuses on Recommendations 
X.3, X.28, and X.29 (informally called the Interac¬ 
tive Terminal Interface [ITI] standards); X.21; 
X.25; and X.75. 


Packet Assembly/Disassembly 

Recommendations X.3, X.28, and X.29 define the 
procedures by which asynchronous terminals, com¬ 
puters, and other devices, often referred to as data 
terminal equipment (DTE), communicate with 
other devices via a packet switched network. 

Packet assemblers/disassemblers, also referred to 
as DTE, commonly serve as network entry/exit 
points. 

X.3 defines the basic and user-selectable func¬ 
tions of a packet assembler/disassembler (PAD). It 
also lists 22 parameters necessary to characterize a 
specific device (e.g., bit rate, the escape character, 
and flow control technique). The proper setting of 
these values enables the PAD to correctly interpret 
the communicating device and vice versa. 

X.28, a related standard, defines the proce¬ 
dures for character interchange and service initial¬ 
ization, the exchange of control information, and 
the exchange of user data between an asynchronous 
terminal device and a PAD. X.29 defines the pro¬ 
cedures for the exchange of PAD control informa¬ 
tion and the manner in which user data is 
transferred between a packet mode DTE and a 
PAD or between two PADS. 

Recommendation X.3 

CCITT Recommendation X.3, Packet Assembly/ 
Disassembly Facility in a Public Data Network , out¬ 
lines the procedures for packet assembly/ 
disassembly in asynchronous transmissions. These 
functions can be programmed and built into a 
microprocessor-based “black box” that is placed 
between the terminal and the X.25 network at ei¬ 
ther the customer’s premises or the entry point of 
the network node. 

The PAD performs a number of functions, 
some of which allow it to be configured, by either 
an asynchronous terminal device or another (re¬ 
mote) PAD, so that its operation is adapted to the 


asynchronous terminal’s characteristics. The 
PAD’s basic functions include: 

• The assembly of characters into packets; 

• The disassembly of the user data field; 

• Virtual call setup, clearing, resetting, and inter¬ 
rupt procedures; 

• Generation of service signals; 

• A mechanism for forwarding packets when the 
proper conditions exist; 

• A mechanism for transmitting data characters, 
including start, stop, and parity elements; 

• A mechanism for handling a break signal from 
an asynchronous terminal; 

• Editing of PAD command signals; 

• A mechanism for setting and reading the cur¬ 
rent value of PAD parameters; 

• A mechanism for the selection of a standard 
profile (optional); 

• Automatic detection of data rate, code, parity, 
and operational characteristics (optional); and 

• A mechanism for the remote DTE to request a 
virtual call between an asynchronous terminal 
and another DTE (optional). 

The PAD’s operation depends on the selectable 
values of internal variables called PAD parameters. 
A set of parameters exists independently for each 
asynchronous terminal. The current value (the bi¬ 
nary representation of the decimal value) of each 
PAD parameter delimits the operational character¬ 
istics of the related function. The initial value of 
each parameter is set according to a predetermined 
set of values, the initial standard profile. Twenty- 
two PAD parameters have been standardized by 
the CCITT. They are as follows: 

• PAD recall using a character —allows an asyn¬ 
chronous terminal to initiate an escape from the 
data transfer state or the connection-in-progress 
state in order to send PAD command signals. 
This parameter has the following selectable val¬ 
ues: not possible, possible by character 1/0 
(DLE), or possible by a user-defined graphics 
character. 

• Echo —enables characters received from the 
asynchronous terminal to be interpreted by the 
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PAD and transmitted back to the asynchronous 
terminal. Selectable values are no echo (0) and 
echo (1). 

• Selection of data forwarding characters —allows 
the asynchronous terminal to send defined sets 
of characters, which the PAD recognizes as an 
indication to complete the packet assembly and 
to forward a complete packet sequence as de¬ 
fined in X.25. The basic functions of this pa¬ 
rameter are encoded and represented by a 
decimal value. The functions include no data 
forwarding character (represented by decimal 
0); alphanumeric characters A-Z, a-z, and 0-9 
(decimal 1); CR (decimal 2); ESC, BEL, ENQ, 
and ACK (decimal 4); DEL, CAN, and DC2 
(decimal 8); ETX and EOT (decimal 16); HT, 
LF, VT, and FF (decimal 32); and all other 
characters in columns 0 and 1 of International 
Alphabet No. 5 (IA5) not included in the above 
(decimal 64). 

• Selection of idle timer delay —permits the selec¬ 
tion of the duration of a time interval between 
successive characters. When data received from 
the asynchronous terminal exceeds this interval, 
the PAD terminates the assembly of a packet 
and forwards it as defined in the X.25 protocol. 

• Ancillary control —defines flow control between 
the PAD and the asynchronous terminal. Deci¬ 
mal 0 represents no use of X-on (DC 1) and X- 
off (DC3); decimal 1 represents use of X-on/X- 
off (data transfer); and decimal 2 represents the 
use of X-on/X-off (data transfer and command). 

• Control of PAD service signals —provides the 
asynchronous terminal with the capability to 
decide whether and in what format PAD service 
signals are transmitted. 

• Selection of operation of the PAD on receipt of 
the break signal —after receiving a break signal 
from the asynchronous terminal, the PAD may 
do nothing, send an interrupt packet to a packet 
mode DTE or another PAD, reset, or send an 
indication of break PAD message to a packet 
mode DTE or another PAD. 

• Discard output —permits a PAD to discard the 
content of user sequences in packets rather than 
disassembling and transmitting them to the 
asynchronous terminal. Selections include nor¬ 
mal data delivery or discard output. 


FEBRUARY 1991 


CCITT Packet Switched Data Networking 

Networking Standards 
X Series 


• Padding after carriage return —permits the PAD 
to automatically insert padding characters in 
the character stream sent to the asynchronous 
terminal after the occurrence of a carriage re¬ 
turn character. This enables the asynchronous 
terminal printing device to perform the carriage 
return function correctly. A value between 0 
and 255 indicates the number of padding char¬ 
acters the PAD will generate. 

• Line folding —permits the PAD to automatically 
insert appropriate format effectors in the char¬ 
acter stream sent to the asynchronous terminal. 
No line folding or a predetermined maximum 
number of graphics characters per line may be 
selected. 

• Binary speed —a read-only parameter that nei¬ 
ther DTE can change. It enables the packet 
mode DTE to access a characteristic (known by 
the PAD) of the asynchronous terminal device. 
Speeds from 50 bps to 64K bps are represented. 

• Flow control of the PAD by the start/stop mode 
DTE —governs flow control between the asyn¬ 
chronous terminal and the PAD. The asynchro¬ 
nous terminal transmits special characters to 
indicate whether it is ready to accept characters 
from the PAD. In IA5, these special characters 
switch an ancillary transmit device on and off. 
Decimal 0 represents no use of X-on (DC1) and 
X-off (DC3); decimal 1 represents use of X-on/ 
X-off. 

• Line-feed insertion after carriage return — 
permits the PAD to automatically insert a line¬ 
feed character in the character stream sent to or 
received from the asynchronous terminal or af¬ 
ter echo of each carriage return character. This 
function applies only in the data transfer state. 

• Line-feed padding —permits the PAD to auto¬ 
matically insert padding characters in the char¬ 
acter stream transmitted to the asynchronous 
terminal after the occurrence of a line-feed char¬ 
acter. This enables the asynchronous terminal 
printing mechanism to perform the line-feed 
operation correctly. This function applies only 
in the data transfer state. 

• Editing —enables character delete, line delete, 
and line display editing capabilities. During the 
PAD command state, the editing function is al¬ 
ways available; use or nonuse of the editing 
function in the data transfer state is selectable. 


© 1991 McGraw-Hill, Incorporated. Reproduction Prohibited. 
Datapro Information Services Group. Delran NJ 08075 USA 



Data Networking 


CCITT Packet Switched 
Networking Standards 
X Series 


2720 

Standards 


5 


• Character delete, line delete, and line display — 
all editing functions represented by one user- 
selectable character from IA5. 

• Editing PAD service signals —enable the asyn¬ 
chronous terminal to edit PAD service signals 
for printing devices and display terminals; also 
used for editing via one character from IA5. 
Editing is not selectable. 

• Echo mask —when echo is enabled, echo mask 
designates that selected defined groups of char¬ 
acters sent by the asynchronous terminal are not 
transmitted back. The following may be se¬ 
lected: no echo mask; no echo of CR; no echo of 
LF; no echo of VT, HT, and FF; no echo of BEL 
and BS; no echo of ESC and ENQ; no echo of 
ACK, NAK, STX, SOH, EOT, ETB, and ETX; 
no echo of editing characters; or no echo of all 
other characters. 

• Parity treatment —permits the PAD to check 
parity in the datastream from the asynchronous 
terminal and/or generate parity in the 

• datastream to the asynchronous terminal. No 
parity checking or generation, parity checking, 
or parity generation are selectable. 

• Page wait —allows the PAD to suspend trans¬ 
mission of additional characters to the asyn¬ 
chronous terminal after the PAD has 
transmitted a specified number of line-feed 
characters. 

Recommendation X.28 

CCITT Recommendation X.28, titled DTE/DCE 
Interface for a Start/Stop Mode Data Terminal 
Equipment Accessing the Packet Assembly/ 
Disassembly Facility (PAD) in a Public Data Net¬ 
work Situated in the Same Country, describes the 
interfacing procedures that allow the PAD to be 
connected to an asynchronous terminal. X.28 cov¬ 
ers four areas: 

• Procedures to establish an access information 
path between an asynchronous terminal and a 
PAD; 

• Procedures for character interchange and ser¬ 
vice initialization between an asynchronous ter¬ 
minal and a PAD; 

• Procedures for the exchange of control informa¬ 
tion between an asynchronous terminal and a 
PAD; and 


• Procedures for the exchange of user data be¬ 
tween an asynchronous terminal and a PAD. 

Modems standardized for use on public switched 
or leased line facilities establish the procedures for 
providing an access path (DTE/DCE interface). 
Procedures for both V and X Series interfaces are 
defined. 

Transmission speeds up to 1200 bps are spec¬ 
ified for V-Series interfaces; they are in accordance 
with either the V.21, V.22, or V.23 standard, de¬ 
pending on facility type and speed. The V-Series 
specifications define the procedures for setting up 
and disconnecting the access information path by 
both the DTE and the PAD. 

X-Series interfaces also are used with 
switched or leased line facilities. The physical char¬ 
acteristics for the DTE/DCE interface are specified 
in X.20 or X.20 bis. Procedures for setting up and 
disconnecting the path by both the DTE and the 
PAD are defined. 

X.28 specifies procedures for character inter¬ 
change and service initialization between an asyn¬ 
chronous terminal and a PAD. Characters sent and 
received must conform to IA5. The PAD transmits 
and expects to receive only eight-bit characters. 

The eighth bit, the last bit preceding the stop ele¬ 
ment, is used for parity checking. 

X.28 describes the action the PAD takes 
when the value of parameter 21 (X.3, parity treat¬ 
ment) is set to 0, 1, 2, or 3. If parameter 21 is set to 
0, the PAD inspects only the first seven bits and 
ignores the eighth bit. When parameter 21 is set to 
1, the PAD treats, the eighth bit of the character as 
a parity bit and checks this bit against the type of 
parity—odd, even, space (0), or mark (1)—used 
between the PAD and the asynchronous terminal. 
If it is set to 2, the PAD replaces the eighth bit of 
the characters to be sent to the terminal with the 
bit that corresponds to the type of parity used be¬ 
tween the PAD and terminal. When the value is set 
to 3, the PAD checks the parity bit for characters 
received from the asynchronous terminal and gen¬ 
erates the parity bit for characters to be sent to the 
asynchronous terminal (as in values 1 and 2). 

Once the access information path is estab¬ 
lished, the asynchronous terminal and the PAD 
exchange binary 1 across the interface. This places 
the interface in the active link state (state 1). When 
the interface is in the active link state, the DTE 
transmits a sequence of characters that indicates 
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service request (state 2) and initializes the PAD. 

The service request permits the PAD to detect the 
data rate, code, and parity used by the asynchro¬ 
nous terminal (DTE) and to select the initial pro¬ 
file of the PAD. The service request may be 
bypassed, if the terminal is connected to the PAD 
via a leased line and the PAD knows the speed, 
code, and initial profile of the terminal or if a de¬ 
fault value is used. After the request service signal 
is transmitted, the DTE transmits binary 1, which 
places the interface in the DTE waiting state (state 
3A). If parameter 6 (X.3, control of PAD service 
signals) is set to 0, the interface immediately enters 
the PAD waiting state (state 5) after receipt of ser¬ 
vice request. If parameter 6 is set to other than 0, 
the PAD transmits the PAD identification PAD ser¬ 
vice signal (indicates PAD and port identity; is net¬ 
work dependent), and the interface enters the 
service ready state (state 4). The DTE then trans¬ 
mits a selection PAD command signal (state 6), and 
the PAD transmits an acknowledgment PAD service 
signal, followed by binary 1, which places the inter¬ 
face in the connection-in-progress state (state 7). 

If parameter 6 is 0, the PAD will not transmit 
PAD service signals. In this case, the interface is 
placed in the connection-in-progress state after re¬ 
ceipt of a valid selection PAD command signal. 

Once the DTE receives the PAD service sig¬ 
nal (state 8) or a sequence of signals in response to 
a PAD command signal, the interface is placed in 
either the PAD waiting state (state 5) or the data 
transfer state (state 9). 

A fault condition exists if a valid service re¬ 
quest signal is not received by the PAD within a 
selectable number of seconds after the transmis¬ 
sion of binary 1. If a fault condition occurs, the 
PAD performs clearing by disconnecting the access 
information path. 

The procedures for the exchange of control 
information between an asynchronous terminal 
and a PAD include PAD command signals, PAD 
service signals, break signals, and prompt PAD ser¬ 
vice signals. PAD command signals flow from the 
DTE to the PAD; they set up and clear a virtual 
call, select a standard profile (PAD parameters) 
that is either CCITT or network defined, request 
current values of PAD parameters, send an inter¬ 
rupt requesting circuit status, and reset a virtual 
call. PAD service signals flow from the PAD to the 
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DTE; they transmit call progress signals, acknowl¬ 
edge PAD command signals, and transmit operat¬ 
ing information of the PAD to the terminal. Either 
the PAD or the terminal can transmit the break 
signal. It provides signaling without losing charac¬ 
ter transparency. The prompt PAD service signal 
indicates the PAD’S readiness to receive a PAD 
command signal. 

The temporary storage of characters in an 
editing buffer provides editing functions in the 
PAD. These functions permit the asynchronous 
terminal to edit characters input to the PAD before 
the PAD processes them. They include character 
delete, line delete, and line display. Character de¬ 
lete removes the last character in the editing; line 
delete removes the contents of the editing buffer. 
Line display causes the PAD to send a format ef¬ 
fector followed by the contents of the editing buffer 
to the terminal. 

Procedures for the exchange of user data be¬ 
tween an asynchronous terminal and a PAD apply 
during the data transfer state. The values of the 
parameters set in X.3 determine which characters 
are transmitted during the data transfer state. For 
example, if parameters 1 (PAD recall using a char¬ 
acter), 12 (flow control of the PAD by the start/ 
stop mode DTE), 15 (editing), and 22 (page wait) 
are set to 0, any character sequence may be trans¬ 
mitted by the asynchronous terminal for delivery 
to the remote DTE during the data transfer state. 

User data is sent to the asynchronous termi¬ 
nal in octets (eight-bit characters) at the appropri¬ 
ate transmission rate for the asynchronous 
terminal; the start/stop bits are added to the data 
characters. Octets are assembled into packets (see 
X.25) and forwarded when enough data has been 
received to fill a packet, when the maximum as¬ 
sembly timer delay period has elapsed, when a data 
forwarding character is transmitted, or when a 
break signal is transmitted (parameter 7 is set to 
other than 0). 

Recommendation X.29 

CCITT Recommendation X.29, titled Procedures 
for the Exchange of Control Information and User 
Data Between a Packet Assembly/Disassembly Fa¬ 
cility (PAD) and a Packet Mode DTE or Another 
PAD, provides the final step. X.29 describes the 
interfacing procedures that allow the PAD to com¬ 
municate with the X.25 network. It defines the 
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procedures for the exchange of PAD control infor¬ 
mation and the manner in which user data is trans¬ 
ferred between a packet mode DTE and a PAD or 
between two PADS. 

Recommendation X.29 specifies that control 
information and user data are exchanged between 
a PAD and a packet mode DTE or between PADs 
using the data fields described in X.25. Interface 
characteristics—mechanical, electrical, functional, 
and procedural—are also defined as in X.25. 

X.29 specifies that the call user data field of 
an incoming call or call request packet going to/ 
from the PAD or the packet mode DTE must con¬ 
sist of protocol identifier and call data fields. A call 
request packet need not contain a call user data 
field to be accepted by the PAD. If the call user 
data field is present, the PAD transmits it, un¬ 
changed, to its destination. 

A call data field’s octets consist of user char¬ 
acters sent from the DTE to the PAD during the 
call establishment phase. This field is limited to 12 
octets. The octet’s bits are numbered 8 to 1; bit 1, 
the low order bit, is transmitted first. 

Bits 8, 7, 6, and 5 of octet 1 of a user data 
field of complete packet sequences are the control 
identifier field. This field, which consists of four 
octets, identifies the facility to be controlled. The 
control identifier field coding for messages to con¬ 
trol a PAD for an asynchronous terminal is 0000. 
When the control identifier field is set to 0000, bits 
4, 3, 2, and 1 of octet 1 are defined as the message 
code field, which is used to identify specific types 
of PAD messages. 

User sequences perform data exchange. They 
are transferred in the user data fields of complete 
packet sequences with the Q bit set to 0. Only one 
user sequence exists per complete packet sequence. 
The PAD transmits all data packets with the D bit 
set to 0. The DTE sends a data packet to the PAD 
with the D bit set to 1. When the PAD receives a 
data packet with the D bit set to 1, it sends the cor¬ 
responding acknowledgment. The PAD may reset 
the virtual call, if it does not support the D bit pro¬ 
cedure. 

Control information is exchanged via PAD 
messages, which contain a control identifier field 
and a message code field that may be followed by a 
parameter field. PAD messages are transferred in 
the user data fields of complete packet sequences 
with the Q bit set to 1. Only one PAD message ex¬ 
ists per complete packet sequence. The PAD sends 


all data packets with the D bit set to 0. The DTE 
may send data packets to the PAD with both the D 
bit and the Q bit set to 1. When the PAD receives a 
data packet with both the Q and D bits set to 1, the 
corresponding acknowledgment is transmitted. The 
PAD may reset the virtual call if it does not sup¬ 
port the D bit procedure. (Figure 5 shows the bit 
positions for the Q and D bits.) 

The PAD forwards a data packet when a set, 
read, or set and read PAD message is received or 
when any of the conditions listed in X.28 exist 
(e.g., enough data has been received to fill a packet, 
the maximum assembly timer delay period has 
elapsed, or a data forwarding character is transmit¬ 
ted). The PAD never forwards an empty data 
packet. 

By sending a set, read, or set and read mes¬ 
sage to the PAD, one can read and change the cur¬ 
rent values of PAD parameters. Upon receipt of 
one of these messages, the PAD delivers to the 
DTE any previously received data before it acts on 
the PAD message. The PAD responds to a read or 
set and read PAD message by sending a parameter 
indication PAD message, which contains a parame¬ 
ter field listing parameter references and current 
values. Set allows the changing of parameters. 

X.29 also discusses invitation to clear proce¬ 
dures, which are used to request that the virtual 
call be cleared by the PAD; interrupt and discard 
procedures, which are used to indicate that the 
asynchronous terminal has requested that the PAD 
discard received user sequences; reset procedures, 
as defined in X.25; error handling procedures by the 
PAD, which define the actions to be taken by the 
PAD when errors are detected; and procedures for 
inviting the PAD to reselect the called DTE (op¬ 
tional), which are used by a packet mode DTE to 
request that the PAD clear the virtual call. 


X.21 Interface Specifications 

The trends in communications engineering lean 
toward all-digital networks and the integration of 
voice and data. Prospective users of these digital, 
integrated networks are concerned about an inter¬ 
face that can provide access to voice, data, video 
teleconferencing, and related services. Currently, a 
wide variety of connectors, electrical standards, 
and user procedures for various services and net¬ 
works exists—leading to almost insurmountable 
technical and economical problems. Therefore, it is 
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likely that standards organizations will develop a 
universal service access interface. Although it would 
require certain extensions, X.21 is currently the 
most likely to become a future standard for a uni¬ 
versal interface in distributed system implementa¬ 
tions. 

CCITT Recommendation X.21, Interface Be¬ 
tween Data Terminal Equipment (DTE) and Data 
Circuit-terminating Equipment (DCE) for Synchro¬ 
nous Operation on Public Data Networks, defines 
the physical characteristics and control procedures 
for an interface between DTEs and DCEs. 

X.21 is the designated interface for CCITT 
Recommendation X.25, a packet-switching proto¬ 
col. X.21 can also be used in a non-packet switched 
environment. At least two X.21-based public data 
circuit switched networks are currently imple¬ 
mented, one in Scandinavia and one in Japan. 

The X.21 standard has not gained wide ac¬ 
ceptance in the United States. The reluctance in 
the U.S. to embrace the X.21 standard is due in 
part to the firm entrenchment of RS-232-C. An¬ 
other factor is the cost of implementing X.21. 

Since X.21 transmits and interprets coded charac¬ 
ter strings, more intelligence must be built into the 
interface, at a higher cost than traditional pin-per- 
function interfaces. 

Certain characteristics of X.21 should ensure 
a more widespread acceptance in the coming years. 
One immense advantage X.21 has over traditional 
interfaces is its capability to assign an almost un¬ 
limited number of functions, because there are no 
functional boundaries associated with connector 
size. Also, X.21 offers a much more sophisticated 
level of control over the communications process. 
Another important feature of X.21 is its inherent 
dialing functions, including the provision for re¬ 
porting the reasons why a call was not completed. 
This eliminates the need for a separate data call 
interface, such as RS-232-Cs companion RS-366- 
A, and in switched facilities, results in improved 
response times. 

Another important aspect is its relationship 
to X.25. As the packet-switching technique be¬ 
comes more widely implemented, the demand will 
be greater for equipment to meet the X.21 stan¬ 
dard. Internationally, the combination of X.21, the 
ISO HDLC protocol, and X.25 has been used to 
form an effective communications path. Another 
boost for X.21 is IBM’s recognition. 
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X.21 has some shortcomings. It does not per¬ 
mit the transmission of control information during 
data transfer. Also, it precludes the insertion of 
data encryption hardware between the DTE and 
the DCE. Another drawback is the need to modify 
the DTE/DCE master/slave protocol techniques 
and to supply special crossover cables to facilitate 
DTE-to-DTE or DCE-to-DCE interconnection. 

X.21 uses a different interfacing technique 
than that which is normally associated with 
physical-level interfaces. Instead of assigning each 
function a specific pin on the connector (e.g., 
CCITT V.24 and EIA RS-232-C), X.21 assigns 
coded character strings to each function. 

The following is a summary of the X.21 stan¬ 
dard, including the functional descriptions of the 
interchange circuits, phases of operation, electrical 
characteristics, and mechanical characteristics. 

Functional Descriptions of Interchange Circuits 

Four types of X.21 interchange circuits are de¬ 
fined: Ground, Data Transfer, Control, and Tim¬ 
ing. These circuits, outlined in Table 2, are 
described below. 

Ground and Common Return Circuits — 
include two types of common return circuits, DTE 
Common Return and DCE Common Return, and 
one ground circuit, Signal Ground. 

Signal Ground (Circuit G) establishes the 
common reference potential for unbalanced 
double-current interchange circuits. If required, it 
reduces environmental signal interference. 

Lowering signaling rates may require two 
common return conductors. In this case, two cir¬ 
cuits, DTE Common Return (Circuit Ga) and DCE 
Common Return (Circuit Gb), are necessary. For a 
further explanation of these circuits, see the Elec¬ 
trical Characteristics section of this report. 

Data Transfer Circuits —include two Trans¬ 
mit and Receive data transfer circuits. 

Transmit (Circuit T) transfers signals from 
the DTE to the DCE during the data transfer 
phase. It also transfers call control signals to the 
DCE during call establishment and other call con¬ 
trol phases. 

Receive (Circuit R) receives signals transmit¬ 
ted by the DCE from a remote DTE during the 
data transfer phase. This circuit also transfers call 
control signals from the DCE during the call estab¬ 
lishment and other call control phases. 
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Control Circuits —include Control and Indi¬ 
cation circuits. 

Control (Circuit C) transmits signals that con¬ 
trol the DCE for a particular signaling process. The 
representation of this signal requires additional 
coding of the Transmit circuit, as specified for the 
procedural characteristics of the interface. During 
the data phase, Circuit C remains in the ON condi¬ 
tion. 

Indication (Circuit I) indicates the call control 
process to the DTE. The representation of this sig¬ 
nal requires additional coding of the Receive cir¬ 
cuit. When Circuit I is on, it signifies that signals 
on the Receive circuit contain information from 
the remote DTE. When Circuit I is off, it signifies a 
control signaling condition, defined by the Circuit 
R bit patterns, as specified by the procedural char¬ 
acteristics of the interface. 

Timing Circuits —includes Signal Element 
Timing and Byte Timing. 

Signal Element Timing (Circuit S) provides 
the DTE with signal element timing information. 
For this function, Circuit S turns on and off for 
nominally equal periods of time. 

X.21 defines different roles for the DTE and 
DCE in regard to signal element timing. During the 
off-to-on transition, the DTE presents a binary sig¬ 
nal on Circuit T and a condition on Circuit C. The 
DCE presents a binary signal on Circuit R and a 
condition on Circuit I during the off-to-on transi¬ 
tion. The DCE transfers the signal element timing 
across the interface as long as the timing source is 
capable of generating this information. 

Byte Timing (Circuit B) provides the DTE 
with eight-bit timing information for synchronous 
transmission. Use of this circuit is not mandatory. 
Circuit B turns off whenever Circuit S is in the ON 
condition, indicating the last bit of the eight-bit 
byte. At all other times within the period of the 
eight-bit byte, Circuit B remains on. 

Phases of Operation 

The X.21 standard defines four phases of opera¬ 
tion: the Quiescent Phase, the Call Control Phase, 
the Data Transfer Phase, and the Clearing Phase. 

Each step of the operational phases places the 
DTE and DCE in a certain state. See Table 3 for a 
listing of these states and their associated signals 
on the interchange circuits. 


Table 2 

. CCITT X.21 Interchange 

Circuits 







Direction 


Inter- 

Name 

to DCE 

from DCE 

Circuit 

change 

Circuit 




Type 

G 

Signal 
ground or 





common 

return 




Ga 

DTE 

common 

return 

X 


Ground 

Gb 

DCE 

common 

return 


X 


T 

Transmit 

X 


Data 

Transfer 

R 

Receive 


X 


C 

Control 

X 



1 

Indication 


X 

Control 

S 

Signal 

element 


X 



timing 




B 

Byte timing 


X 

Timing 


Quiescent Phase —the quiescent phase is the 
period during which the DTE and the DCE signal 
their capability to enter the call control phase or 
the data transfer phase. It is characterized by the 
appearance of basic quiescent signals from the 
DTE and DCE. Various combinations of these qui¬ 
escent signals result in different interface states, or 
quiescent states. 

There are three DTE quiescent signals. DTE 
Ready indicates the readiness of the DTE to enter 
the other operational phases. DTE Uncontrolled 
Not Ready indicates the DTE is unable to enter 
certain operational phases, usually due to an ab¬ 
normal condition. DTE Controlled Not Ready indi¬ 
cates that although the DTE is operational, it is 
temporarily unable to accept incoming calls for 
circuit switched service. 

There are two DCE quiescent signals: DCE 
Ready and DCE Not Ready. DCE Ready indicates 
the DCE is ready to enter operational phases. DCE 
Not Ready indicates that no service is available; it 
is also signaled whenever possible during network 
fault conditions and during the period when test 
loops are activated. 
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Table 3. X.21 States: Names, Signalling, and Transitions 


State 

Number State Name 

Phase 

of 

Opera¬ 

tion 

Signals on T,C and R,l Circuits 

T C R 1 

DTE 
to state 
number 

Transitions* 

DCE 
to state 
number 

1 

Ready 

Q 

1 

OFF 

1 

OFF 

2,13S,14,24 

8,13R,18 

2 

Cali request 

CC 

0 

ON 

1 

OFF 

— 

3,15 

3 

Proceed-to-select 

CC 

0 

ON 

+ 

OFF 

4,15 

— 

4 

Selection signal 

CC 

IA5 

ON 

+ 

OFF 

5 

— 

5 

DTE Waiting 

CC 

1 

ON 

+ 

OFF 


6A,11,12 

6A 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

— 

7,10,11,12 

6B 

DCE Waiting 

CC 

1 

ON 

SYN 

OFF 

— 

10 bis, 11,12 

7 

Call progress signal 

CC 

1 

ON 

IA5 

OFF 

— 

6A,10,11,12 

8 

Incoming call 

CC 

1 

OFF 

BEL 

OFF 

15,9 

— 

9 

Call accepted 

CC 

1 

ON 

BEL 

OFF 

— 

6B.11.12 

10 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

— 

6A,11,12 

10 bis 

DCE provided information 

CC 

1 

ON 

IA5 

OFF 

— 

6B,11,12 

11 

Connection in progress 

CC 

1 

ON 

1 

OFF 

— 

12 

12 

Ready for data 

CC 

1 

ON 

1 

ON 

— 

13 

13 

Data transfer 

DT 

D 

ON 

D 

ON 

13R 

13S.DCE 









not ready 

13R 

Receive data 

DT 

1 

OFF 

D 

ON 

13 

1 

13S 

Send data 

DT 

D 

ON 

1 

OFF 

7 

13 

14 

DTE Controlled not ready, DCE 









ready 

Q 

01 

OFF 

1 

OFF 

1,24 

23 

15 

Call collision 

CC 

0 

ON 

BEL 

OFF 

— 

3 

16 

DTE Clear request 

C 

0 

OFF 

X 

X 

— 

17 




(see 









Note) 






17 

DCE Clear confirmation 

c 

0 

OFF 

0 

OFF 

— 

21 

18 

DTE Ready, DCE Not ready 

Q 

1 

OFF 

0 

OFF 

22 

1 

— 

DCE Not ready 

Q 

D 

ON 

0 

OFF 

— 

1,13,13S 

19 

DCE Clear indication 

C 

X 

X 

0 

OFF 

20 

— 




(see 









Note) 






20 

DTE Clear confirmation 

C 

0 

OFF 

0 

OFF 


21 

21 

DCE Ready 

C 

0 

OFF 

1 

OFF 

1 

— 

22 

DTE Uncontrolled not ready, DCE 








not ready 

Q 

0 

OFF 

0 

OFF 

18 

24 

23 

DTE Controlled not ready, DCE 









not ready 

Q 

01 

OFF 

0 

OFF 

18,22 

14 

24 

DTE Uncontrolled not ready, DCE 








ready 

Q 

0 

OFF 

1 

OFF 

1 

22 

Any 









state 









(see 









Note) 



X 

X 

X 

X 

16 

19 


*AII other transitions are considered invalid. 

Note: DCE Clear indication or DTE Clear request may be entered from any state except Ready. 


Key to Table: 

Q—Quiescent Phase 
CC—Call Control Phase 
DT—Data Transfer Phase 
T—Transmit interchange circuit 
C—Control interchange circuit 
R—Receive interchange circuit 
I—Indication interchange circuit 


0 and 1—Steady binary conditions 
01—Alternate binary 0 and binary 1 
X—Any value 

OFF—Continuous off (binary 1) 

ON—Continuous on (binary 0) 

IA5—Characters from CCITT Alphabet #5 
H— IA5 character 2/11 
BEL—IA5 character 0/7 
SYN—IA5 character 1/6 
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There are six quiescent states: 

• Ready 

• DTE Controlled Not Ready, DCE Ready 

• DTE Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Not Ready 

• DTE Controlled Not Ready, DCE Not Ready 

• DTE Uncontrolled Not Ready, DCE Ready 

See Figure 1 for a diagram of the quiescent states 
and the transitions that are allowed between these 
states. 

Call Control Phase —the call control phase for 
circuit switched service contains many elements 
and procedures. Characters used for call control 
are selected from IA5, a seven-bit plus parity inter¬ 
national code outlined in CCITT Recommenda¬ 
tion V.3. Each call control sequence to and from 
the DCE is preceded by two or more continuous 
SYN characters. For error checking of call control 
characters, odd parity is specified. 

The following elements of the call control 
procedure are outlined in X.21: events of call con¬ 
trol procedures, unsuccessful call, call collision, 
direct call, and facility registration/cancellation 
procedure. These elements are summarized below. 

The events of the call control procedures in¬ 
clude the following: 

• Call Request, signaled by the DTE to indicate a 
request for a call. 

• Proceed to Select, used when the network is pre¬ 
pared to receive selection information. It is 
transmitted by the DCE to the DTE within 
three seconds of the call request signal. 

• Selection Signal Sequence, transmitted by the 
DTE. A selection sequence consists of a facility 
request block, an address block, a facility re¬ 
quest block followed by an address block, or a 
facility registration/cancellation block. A facil¬ 
ity request block comprises one or more facility 
request signals, which consist of a facility re¬ 
quest code containing one or more facility pa¬ 
rameters. An address block contains one or 
more address signals. Address signals consist of 
either a full address signal or an abbreviated 
address signal. 

• DTE Waiting. 


• Incoming Call, indicated by the DCE. In re¬ 
sponse, the DTE signals Clear Request, DTE 
Uncontrolled Not Ready, or DTE Controlled 
Not Ready. 

• DCE Waiting. 

• Call Progress Signal Sequence is transmitted by 
the DCE to the calling DTE to indicate that cir¬ 
cumstances have arisen to prevent the connec¬ 
tion from being established, to report the 
progress made toward establishing the call, or to 
signal that problems have been detected and 
that the call needs to be cleared and reset. 

• DCE-Provided Information Sequence, transmit¬ 
ted from the DCE to the calling DTE. It consists 
of DCE-provided information blocks, such as 
line identification and charging information. 
Line Identification is transmitted by the DCE 
to the calling DTE during the DCE-Provided 
Information state immediately after all call 
progress signals, if any, are transmitted. Both 
calling and called line identification are op¬ 
tional. Line identification consists of the inter¬ 
national data number, as assigned in CCITT 
Recommendation X.121, International Num¬ 
bering Plan for Public Data Networks. The DCE 
transmits Charging Information during the 
DCE-Provided Information state. It informs the 
subscriber of either the monetary charges for a 
call, the duration of the call, or the number of 
units used during the call. 

• Connection-In-Progress, indicated by the DCE. 

• Ready for Data, transmitted by the DCE when 
the connection is available for data transfer be¬ 
tween DTEs. 

An unsuccessful call occurs when a required con¬ 
nection cannot be established. In this case, the 
DCE indicates the failure and its reason to the call¬ 
ing DTE through a call progress signal. 

A call collision can occur in one of two ways: 
a DTE detects a call collision when it receives In¬ 
coming Call in response to Call Request. A DCE 
detects a call collision when it receives Call Re¬ 
quest in response to Incoming Call. When the DCE 
detects a call collision, it will indicate Proceed to 
select and cancel the incoming call. 
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The DTE indicates a request for a direct call 
by signaling DTE Waiting after receiving the Pro¬ 
ceed to Select signal. If necessary, the DTE may 
choose an addressed call by presenting the correct 
Selection signal. 

The facility registration/cancellation proce¬ 
dure is optional. A facility registration/cancellation 
signal consists of up to four elements in order: fa¬ 
cility request code, indicator, registration parame¬ 
ter, and address signal. Not all of these elements 
are required in the facility registration/cancellation 
signal. Also, a number of these signals may be 
linked to form a block. In response to acceptance 
or rejection of the facility registration/cancellation 
action, the network provides the appropriate Call 
Progress Signal. 

Data Transfer Phase —when the DTE is in the 
data transfer phase, any bit sequence may be trans¬ 
mitted. X.21 defines the data transfer phase for 
three types of connections: switched; leased, point 
to point; and leased, centralized multipoint. 


CCITT Packet Switched Data Networking 

Networking Standards 
X Series 


For operation over switched facilities, the 
DTE may send bits to a corresponding DTE after 
receiving the Ready for Data signal. During data 
transfer, control and interchange circuits are in the 
ON condition, and data is transmitted over the 
transmit and receive circuits. Data transfer may be 
terminated by clearing , which is defined below. 

Two basic signals are used for operation over 
leased, point-to-point facilities. Send Data trans¬ 
mits data by the DTE on Circuit T; the remote 
DTE’s Receive Data signal receives data over Cir¬ 
cuit R. To terminate the data transfer, the DTE 
signal places its transmit circuit in the binary 1 
condition. The DCE indicates termination of data 
transfer by placing its receive circuit in the binary 
1 condition, its control circuit in the OFF condi¬ 
tion, and its indications circuit in the OFF condi¬ 
tion. 

Both the central and remote DTEs use the 
Send Data and Receive Data signals for operation 
over leased, multipoint facilities. The central DTE 


Figure 1. 

Quiescent States 



IMinition?; 



* 


n State number 
t Signal on T circuit 

c Signal on C circuit 

r Signal on R circuit 

i Signal on I circuit 

I Transition with indication 
1 of whether DTE or DCE 
T is responsible for transition 


The above diagram indicates transitions that are allowed in X.21 networks. Other transitions are possible and 
may be allowed in some networks. See Table 3 for a listing of possible transitions. 
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delivers data transmitted to all remote DTEs; re¬ 
mote DTEs (one at a time) transmit data to the 
central DTE. A remote DTE may send data to the 
central DTE while the central DTE is sending to all 
remote DTEs. 

Clearing Phase —either the DTE or the DCE 
may initiate clearing. The DTE indicates its desire 
to enter the clearing phase by transmitting DTE 
Clear Request. The DCE responds by signaling 
DCE Clear Confirmation, followed by DCE Ready. 

Clearing by the DCE takes place when it 
transmits DCE Clear Indication. The DTE re¬ 
sponds with the DTE Clear Confirmation signal, 
followed by the DCE signaling DCE Ready. 

Electrical Characteristics 

X.21 uses two types of electrical characteristics, 
each for different system requirements. 

For synchronous operation at 9600 bps and 
below, the interchange circuits at the DCE side of 
the interface must comply with CCITT Recom¬ 
mendation X.27. The DTE side can comply with 
either X.27 or another CCITT Recommendation, 
X.26. For synchronous operation at signaling rates 
above 9600 bps, interchange circuits at both the 
DTE and DCE sides of the interchange circuits 
must comply with X.27. 

X.26 is defined in CCITT Standard V.10. It 
describes the electrical characteristics for unbal¬ 
anced interchange circuits. X.26 calls for both a 
DTE and DCE common grounding arrangement. 
The maximum suggested cable length is 1,000 
meters, and the maximum data rate is 100K bps. 

X.27 is defined by CCITT Standard V.l 1, 
which describes the electrical characteristics for 
balanced operation. Maximum suggested cable 
length is 1,000 meters, and the maximum data rate 
is 10M bps. 

Mechanical Characteristics 

The mechanical characteristics for X.21 are out¬ 
lined in the ISO Standard 4903, approved by the 
International Organization for Standardization 
(ISO). The standard, entitled Data 
Communication — 15-pin DTE/DCE Interface Con¬ 
nector and Pin Assignments, was published in June 
1980. 


ISO 4903 assigns connector pin numbers to a 
15-pin interface between DTE and DCE equip¬ 
ment. Table 4 presents a chart of these X.21 pin 
assignments as they relate to the X.26 and X.27 
standards. 

X.21 Bis 

Although X.21 is the specified interface for X.25, 
alternative interfaces also exist. One of these is 
X.21 bis. 

CCITT Recommendation X.21 bis, the physi¬ 
cal and functional equivalent to CCITT V.24, de¬ 
fines 25 interchange circuits between DTEs and 
DCEs. CCITT V.24 is compatible with EIA Stan¬ 
dard RS-232-C. The X.21 bis recommendation, 
accepted as the interim interface for X.25, will be 
gradually replaced by X.21 as more equipment is 
manufactured to meet X.21 specifications. 


Recommendation X.25 

The development of Recommendation X.25 was 
stimulated by the need for a standard interface be¬ 
tween the packet-switching networks already devel¬ 
oped or being developed by many industrial 
nations and by the requirement that no terminal 
equipment be denied access to packet switched ser¬ 
vices. 

X.25 is a dynamic standard with many varia¬ 
tions in the U.S. and abroad. Currently, X.25- 
based packet switched networks exist in Australia, 
Austria, Belgium, Canada, France, Ireland, Ger¬ 
many, Hong Kong, Italy, Japan, Mexico, the Neth¬ 
erlands, Portugal, Singapore, the Soviet Union, 
South Africa, Spain, Switzerland, the United King¬ 
dom, and the United States. Since X.25 is a dy¬ 
namic standard with many extensions and optional 
features, these networks are not totally compatible 
with one another. Those located in Europe have 
the highest level of mutual compatibility. 

Since the establishment of X.25, additional 
user-level protocols have been developed. These 
protocols provide the interfaces between different 
types of terminals and the X.25 interface. X.3, 
X.28, and X.29, informally called the Interactive 
Terminal Interface (ITI), were the first of the pro¬ 
tocols to interface to X.25. They relate to the sup¬ 
port of asynchronous, low-speed terminals by 
packet switched networks. These are logical com¬ 
plements to X.25 because they permit specific sets 
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of terminals to interface to the packet networks 
using the X.25 interface. 

The X.25 interface standard provides for the 
connection of terminals and computers to public 
packet-switching networks. X.25 outlines three lay¬ 
ers of operation: the Physical Layer, the Link 
Layer, and the Packet Layer. These layers parallel 
the bottom three layers of the ISO Reference 
Model for Open Systems Interconnection. The 
Physical Layer calls for CCITT X.21 as the physi¬ 
cal and electrical interface but accepts X.21 bis, a 
functional equivalent of RS-232-C, as an interim 
standard. The Link Layer uses the procedures of 
the HDLC protocol standard. The Packet Layer 
defines procedures for constructing and controlling 
a data packet. 

The 1984 revision of Recommendation X.25 
added specifications for X.21 access and expanded 
the potential of packet operations, allowing users 
to actively gain access to the X.25 port, identify 
themselves, and validate their connection through 
passwords. This change reoriented the X.25 stan¬ 
dard toward switched access through both X.21 
facilities and the public telephone network. It now 


Table 4. 

X.21 Pin Assignments 

Pin 

Number 

Employing 

X.26 

Employing 

X.27 

1 

See Note (3) 

See Note (3) 

9 

Ga 

T(B) 

2 

T 

T(A) 

10 

Ga 

C(B) 

3 

C 

C(A) 

11 

R(B) 

R(B) 

4 

R(A) 

R(A) 

12 

1(B) 

1(B) 

5 

1(A) 

1(A) 

13 

S(B) 

S(B) 

6 

S(A) 

S(A) 

14 

B(B) 

B(B) 

7 

B(A) 

B(A) 

15 

Reserved for 
future use 

Reserved for 
future use 

8 

G 

G 


Notes: 

(1) X.21 pin assignments are defined by ISO 4903-1980. 

(2) Where balanced ciruits are, the associated pairs are desig¬ 
nated “A" and "B." 

(3) Pin 1 is reserved for connection of the shield or shielded in¬ 
terconnecting cable. 
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supports X.32 with regard to the public switched 
telephone network or a circuit switched public data 
network, dial-in and dial-out access, backup for 
leased line connections, long-distance access to the 
network, and teletex. 

Datagram was deleted in 1984. while the fol¬ 
lowing packet-level services were made available as 
options: 

• Registered Private Operating Agent (RPOA) Se¬ 
lection permits the use of one or more networks 
to route a call to its destination. If the user se¬ 
lects only one network, either the basic or ex¬ 
tended format of the RPOA Selection can be 
used; if more than one network is chosen, the 
extended format is used. 

• Call Redirection permits the rerouting of calls if 
the first tried route fails. 

• Call Redirection Notification informs the recipi¬ 
ent of the forwarded call that the call has been 
redirected. 

• Called Line Address Modified Notification tells 
the caller, within a call confirmation packet, 
that the call has been redirected. 

• Hunt Group distributes incoming calls that have 
an address associated with the hunt group. 

• Charging Information gives the caller informa¬ 
tion on time and charges and requires a new 
field in the call-clearing packet format. 

• Local Charging Prevention is a security facility 
that prevents reverse or third-party call charges. 

• Network User Identification accommodates user 
ID, billing, and on-line facilities registration. 
This permits users to communicate directly 
with the packet data network to change the pa¬ 
rameters of their subscriptions. 

The packet level is an octet-oriented (eight bits per 
octet) structure. Packet sizes can vary from 1,024 
to 2,048 octets, but only within a network. 
Network-to-network exchange is limited to 128 
octets. Closed user group facilities can accommo¬ 
date very large private-packet networks, although 
the number of closed user groups to which a DTE 
can belong is network dependent. 

Link-level changes implemented in 1984 cre¬ 
ated a clear separation between the Link Access 
Procedure (LAP) and the Link Access Procedure 
Balanced (LAPB). Multilink procedures for a single 
interface were also implemented. LAPB underwent 
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an alignment with the single-link procedure of 
X.75. An extended numbering option (modulo 
128) was added to LAPB to enable the sequencing 
of 127 frames and the use of satellite facilities. In 
addition, the 1984 revisions to X.25 refined the 
procedure for the implementation of the D-bit, 
polished technical accuracy, and defined the rules 
for new fields and formats. 

X.25 Communications 

X.25 is titled Interface Between Data Terminal 
Equipment (DTE) and Data Circuit-terminating 
Equipment (DCE) for Terminals Operating in the 
Packet Mode on Public Data Networks. It provides 
a precise set of procedures for communications 
between DTE and DCE for terminal equipment 
operating in a packet environment. The DCE in 
this case is a node processor that serves as an 
entry/exit point on the packet network side of the 
user/network interface. 

The Data Terminal Equipment (DTE) is a 
programmable device on the user side of the user/ 
network interface. The DTE is located at the user 
site when the on-site equipment supports X.25; at 
such installations, the DTE can be either a com¬ 
puter, a front-end processor, or an intelligent ter¬ 
minal, as shown in Figure 2. The DTE can be a 
group of intelligent terminals (multiplexed to avoid 
the use of multiple lines) that transmit data over 
the packet network to a remotely located host. It 
can also be a processor acting on calls received 
from multiple locations that communicate over the 
packet network. 

Regardless of the device or application, all 
DTEs present standard formatted data and control 
information to the DCE over standard communi¬ 
cations facilities. Devices operate over the network 
in the virtual circuit mode. Essentially, the user 
causes the network to establish a logical circuit 
connection with the receiving station for the trans¬ 
mission of multiple contiguous packets. (The ac¬ 
tual physical circuit over which individual packets 
are transmitted can vary during a session, but the 
logical circuit ensures presentation of each packet 
to the receiving station in the proper order.) Infor¬ 
mation delivery is so rapid that the user appears to 
have an end-to-end, dedicated channel. 

Users who do not support X.25 can access the 
public data network for packet data transmission; 
however, they cannot transmit directly to a DCE or 
network node. They must transmit to a special 


network-operated PAD, discussed earlier in this 
report. Terminal transmissions are stored in a 
buffer at the PAD. There they are assembled into 
packets and sent to the device at the other end of 
the virtual circuit. Packets arriving at the PAD 
from the network are reassembled into the appro¬ 
priate format before they are sent on to the termi¬ 
nal. The PAD is programmed and configured to 
interface properly with the protocol and physical 
characteristics of the user’s device. Data presented 
to the PAD is reformatted into X.25 format and 
forwarded to the DCE. 

Recommendation X.25 is divided into those 
specifications required for a device or network to 
comply and those that are optional. Approximately 
one third are required; the remaining two thirds of 
the specifications are optional. 

The excess throughput capacity inherent in 
the X.25 standard allows for future network growth 
and technological progress. For example, a single 
X.25 interface can theoretically handle 4,095 vir¬ 
tual channels, packet sizes up to 2,048 bytes each, 
and packet sequencing up to 128 packets per logi¬ 
cal channel. Most network suppliers’ nodal proces¬ 
sors are too small to handle this much traffic 
through a single interface. Therefore, in practice, 
the support offered over each interface is limited to 
the current capacity of the network’s access node. 

Functional Layers 

Recommendation X.25 defines three functional 
layers: the Physical Layer (Level 1), the Link Layer 
(Level 2), and the Packet Layer (Level 3). These are 
consistent with the first three layers of the ISO Ref¬ 
erence Model for Open Systems Interconnection 
(OSI). (Although OSI labels its third layer the Net¬ 
work Layer, its function parallels that of the Packet 
Layer. Both provide the means to establish, main¬ 
tain, and terminate connections.) 

Level 1: Physical Level —outlines the physical, 
functional, and electrical characteristics of the 
DTE/DCE interface. X.21 uses the transmission of 
coded character strings across a 15-pin connector 
to define standard interface functions, e.g.. Trans¬ 
mit Data. Its specifications are defined in CCITT 
Recommendation X.21. 

Although X.21 is the recommended physical- 
level interface for X.25, the availability of data 
communications equipment with X.21 capabilities 
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Figure 2. 

A Sample User Terminal Configuration for Operating on a Public Data Network (PDN) in Packet Mode, with 
X.2S as the Interface to the Network 


User Location Public Packet-Switching Network 



4) Signifies an interface that must conform to X.25 Level 2, Physical Interface Standards. 


is limited, especially in the United States. As a re¬ 
sult, the CCITT has accepted an interim recom¬ 
mendation, X.21 bis, as the X.25 physical 
interface. X.21 bis is functionally equivalent to 
EIA RS-232-C, which assigns a separate function 
to each pin across a 25-pin connector. 

Level 2: Link Level —describes the link access 
procedures used for data interchange between a 
DCE and a DTE. In the CCITT Recommendation 
X.21, International User Classes of Service in Pub¬ 
lic Data Networks, X.25 specifies that the DTE and 
DCE must operate in the following user classes of 
service: class 8 (2400 bps), class 9 (4800 bps), class 
10 (9600 bps), or class 11 (48K bps). The proce¬ 
dure calls for a full-duplex facility so that the DTE 
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and DCE can conduct two-way, simultaneous, in¬ 
dependent transmissions. The procedures use the 
principles and terminology of the High-level Data 
Link Control (HDLC) protocol specified by the 
International Organization for Standardization. 

Level 2 comprises three procedures: the Link 
Access Procedure (LAP), the Link Access Proce¬ 
dure Balanced (LAPB), and the Multilink Proce¬ 
dure (MLP). The original X.25 data link control 
procedure embraced LAP, which is similar to the 
HDLC Asynchronous Response Mode (ARM). 
Due to some incompatibilities with some elements 
of procedures, Level 2 of the X.25 Recommenda¬ 
tion was revised to incorporate LAPB. Similar to 
the Asynchronous Balanced Mode (ABM) of 
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HDLC, it provides for a “balanced” configuration; 
that is, each side of the link consists of a combined 
primary/secondary station. The Multilink Proce¬ 
dure is used for data transmission on one or more 
single links. Each link conforms to the X.25- 
defined frame structure and to the elements of pro¬ 
cedure described in LAPB. 

Software in both DTE and DCE performs 
Level 2 processing. This software appends control 
information onto packets that are ready for trans¬ 
mission, maintains control of the transmissions, 
performs transmission error checking, and strips a 
successfully received frame down to a packet. The 
packet consists of packet control information and 
(optionally) user data; packets are discussed in de¬ 
tail later in this report. 

HDLC specifies certain control fields that 
must be appended to both ends of a packet, result¬ 
ing in a transmission format called a frame. Ap¬ 
pended in front of a packet are a beginning Flag 
field, an Address field, and a Control field. Ap¬ 
pended behind the packet are a Frame Check Se¬ 
quence field and a closing Flag field. Figure 3 gives 
the Size and description of each field. The receiving 
device uses the two Flag fields to ascertain the be¬ 
ginning and ending of a frame. A single Flag field 
can be used as the closing flag for one frame and 
the opening flag of the next frame. The Address 
field, under HDLC, is used to identify the sta¬ 
tion^) for which the command is intended in com¬ 
mand frames or to identify the station sending the 
response in response frames. 

The Control field identifies the type of frame 
and supplies control information pertinent to that 
type of frame. A frame can be either an Informa¬ 
tion Frame (I-Frame), a Supervisory Frame (S- 
Frame), or an Unnumbered Frame (U-Frame). See 
Table 5 for the encoding of this field. 

An Information Frame contains a user 
packet. The Control field of the I-Frame contains 
the N(S) transmitter Send Sequence Count, the 
N(R) transmitter Receive Sequence Count, and the 
Poll/Final (P/F) bit. N(S) is the sequence number 
of this frame sent from this transmitter to this re¬ 
ceiver. N(R) is the sequence number of the next 
frame this transmitter expects to get from the re¬ 
ceiver when the receiver becomes a transmitter. 

The Poll/Final bit indicates whether a transmission 
acknowledgment is required or when the final 
frame in a stream has been transmitted. 


The Supervisory Frame transmits one of 
three supervisory commands and cannot contain 
user data. The Control field of the S-Frame con¬ 
tains the command, the P/F bit, and an N(R). 

Table 6 summarizes the commands and responses 
possible in the Control field. 

The Unnumbered Frame extends the number 
of link control functions, without incrementing the 
sequence counts at either the sending or receiving 
station. 

A U-Frame control field contains the Un¬ 
numbered command and the P/F bit. One of the 
U-Frame commands initializes the DTE/DCE net¬ 
work to the Asynchronous Response Mode (ARM) 
of operation, which permits both DTE and DCE to 
initiate transmission to each other. 

The Frame Check Sequence (FCS) field con¬ 
tains a 16-bit check pattern created at framing time 
by generating check bits based upon the binary 
value of the data in the packet. The receiving de¬ 
vice performs the same calculation and compares 
its results with the value that the sending device 
had placed in the FCS field. If these values do not 
agree, the frame has a transmission error and is 
discarded. Discarding causes the receiving device 
to send an S-Frame with the Reject Recovery com¬ 
mand. This S-Frame contains the frame numbered 
N(R), thus acknowledging receipt of all frames 
numbered N(R)-1 and below, and initiates retrans¬ 
mission of frames N(R) and above. 

In effect, Level 2 envelops the packet in con¬ 
trol information and prescribes procedures that 
ensure a high degree of transmission accuracy and 
detection of lost frames during transmission. 

Level 3: Packet Level —describes the packet 
format and control procedures for the exchange of 
packets between the DTE and the DCE. In addi¬ 
tion to the user data packet format, there are sev¬ 
eral formats for DTE/DCE administrative 
messages. 

The software for formatting packets and con¬ 
trolling packet exchange is the Level 3 software 
resident in both the DTE and the DCE. Figure 4 
shows the relationship of Level 3 and Level 2 soft¬ 
ware operating in the DTE and the DCE. In the 
DTE, a user application program normally pre¬ 
sents the data to be transmitted to the operating 
system’s communications access method. The ac¬ 
cess method invokes Level 3 software to append 
the packet header information, then invokes Level 
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Figure 3. 

Frame Formats for Packet Mode Transmission 


-Frame- 


Fields Generated by: 
Application Program 
Level 3 Software 
Level 2 Software 






Flag 

Address 

Control 

Field 

Packet 

Control 

Infomation 

User Data 

Field 

Sequence 

Check 

Flag 

i- 

1 


! 

i 

1 

1 

1 


1 

i 

1 

1 


• 

1 





1 _ 

1 

1 

_ i 


Field 


Flag 

Address 


Size, 

bits Description 

8 Value is 01111110. 

8 Value for DTE to DCE command frame is "10000000-. 

Value for DTE to DCE response frame is "11000000*. 


Value for DCE to DTE command frame is "11000000". 
Value for DCE to DTE response frame is "10000000". 


Control 


8 I Frame: 

Bit 1 is "0". 

Bits 2, 3, 4, are N(S) (transmitter send sequence count). 
Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receive sequence count). 


S Frame: 

Bit 1 is "1". 

Bit 2 is "0". 

Bits 3, 4 identify Supervisory Command. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are N(R) (transmitter receiver sequence count). 

U Frame: 

Bit 1 is 1. 

Bit 2 is 1. 

Bits 3, 4 are first part of Unnumbered Frame Command identifier. 

Bit 5 is P/F (Poll/Final) bit. 

Bits 6, 7, 8 are second part of Unnumbered Frame Command identifier. 

Packet 
Control 
User Data 

Field Sequence 
Check 

Flag 


24 Control information. 

1,024 1,024 data bits are normal maximum; exceptional maximum is 2,040 data bits 

16 Check bits for user data. 

8 Value is "01111110". 


2 software to create the frame. Packet header for¬ 
mats are discussed below. 

Once the frame is created, it is ready for 
transmission. Upon receiving the frame, the receiv¬ 
ing DCE invokes Level 2 software to perform error 
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detection and sequence checking and to strip the 
accepted frame down to a packet. The packet is 
presented to Level 3 software for packet-level pro¬ 
cessing and to prepare the packet for transmission 
to the destination DCE. The physical address of 
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Table 5. X.25 Level 2 Commands and Responses 


Commands (1) Responses Encoding of Control Field 


Format 




1 

2 

3 

4 

5 

6 

7 8 

Information 

transfer 

1 

(information 


0 


N(S) 


P 


N(R) 

Supervisory 

RR (3) 

(receive ready) 

RNR 

(receive not ready) 1 

0 

0 

0 

P/F 


N(R) 


RNR (3) 

(receive not ready) 

RNR 

(receive not ready) 1 

0 

1 

0 

P/F 


N(R) 


REJ (3) 

(reject) 

REJ 

(reject) 1 

0 

0 

1 

P/F 


N(R) 

Unnumbered 

SARM 

(set asynchronous 

DM 

(disconnected 








(2,3) 

response mode) 

(2) 

mode) 1 

1 

1 

1 

P/F 

0 

0 0 


SABM 

(set asynchronous 










(2) 

balanced mode) 


1 

1 

1 

1 

P 

1 

0 0 


DISC 

(disconnect) 


1 

1 

0 

0 

P 

0 

1 0 




UA 

(unnumbered 
acknowledgment) 1 

1 

0 

0 

F 

1 

1 0 




CMDR 

(command reject) 1 

1 

1 

0 

F 

0 

0 1 




FRMR 

(frame reject) 








Note 1: The need for, and use of, additional commands and responses are for further study. 

Note 2: DTEs do not have to implement both SARM and SABM, furthermore DM and SABM need to be used if SARM only is used. 
Note 3: RR, RNR and REJ supervisory command frames are not used by the DCE when SARM is used (LAP). 


the destination DTE, derived from the call initia¬ 
tion, is inserted into the packet during Level 3 pro¬ 
cessing. At the network destination DCE, Level 3 
software reformats the packet control information 
and presents the resulting packet to Level 2 soft¬ 
ware; Level 2 software includes the packet in a 
frame for transmission to the destination DTE 
(user). At the destination DTE (user), Level 2 soft¬ 
ware performs error detection and sequence check¬ 
ing and strips accepted frames down to the packet. 
Level 3 software is then applied to the packet to 
strip the header information from the packet and 


pass the user information to the appropriate appli¬ 
cation program via the communications access 
method. Table 7 summarizes the types of packets 
exchanged between terminals. 

The Packet Header consists of three octets. In 
Octet 1, the first four bits represent the Logical 
Channel Group Number, and the final four bits 
represent the General Format Identifier. Octet 2 
represents the Logical Channel Number, and Octet 
3 represents the Packet Type Identifier. See 
Figure 5. 


Table 6. Summary of Packets Exchanged between Terminals during a Virtual 
Call 


Events 

Activity at Calling DTE 

Activity at Called DTE 

Call Initiation 

Call Request packet is sent 

Incoming Call packet is received 
Call Accepted packet is sent 


Call Connected packet is received 


Data Transfer 

Data packet sent 

Data packet received 

Ready Receive packet sent 


Ready Receive packet received 

Data packet A sent* 

Data packet B received* 

Data packet B sent* 

Data packet A received* 

Disconnect 

Clear Request packet sent 

Clear Indication packet received 
Clear Confirmation packet sent 


Clear Confirmation packet received 



* Two-way (full-duplex) transmission of data packets between terminal equipment. 
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The Logical Channel Group Number and the 
Logical Channel Number provide the routing infor¬ 
mation that directs the packet over one of the logi¬ 
cal channels. The numbering system for the logical 
channels is dynamic and refers to a switched data 
path within the packet network. 

The General Format Identifier indicates the 
general format of the rest of the header. Specific bit 
patterns are established for the following: call setup 
packets; clearing, flow control, interrupt, reset, re¬ 
start, and diagnostic packets; and data packets. 

The Packet Type Identifier establishes the 
packet’s function. Examples of functions include 
call setup, priorities, and data. If applicable, it may 
identify the packet’s place in sequence. See Table 7 
for the various packet types. 

Packet-Level Procedures 

X.25 Level 3 defines procedures for call initiation, 
data transfer, interrupts, reset, restart, and clear¬ 
ing. Some of these procedures are summarized be¬ 
low. 

Call Initiation'. The Level 3 software in a 
DTE initiates a transmission by sending a Call Re¬ 
quest packet. This packet enables the calling DTE 
to request the opening of a logical channel. The 
calling DTE designates the channel number based 
upon the original assignments that were made 


CCITT Packet Switched 
Networking Standards 
X Series 


when the user subscribed to the network. The Call 
Request packet also informs the network of the 
calling DTE's address and of the called DTE's ad¬ 
dress. Until the call is disconnected, the network 
retains the addresses of both devices associated 
with the logical channel number. Therefore, each 
data packet that is transmitted needs to contain 
only the logical channel number. The network ap¬ 
pends the destination address just before routing 
the packet. At the time the Call Request is issued, 
the logical channel indicated by the calling DTE 
must be in a Ready state, that is, not being used to 
handle another call. Upon receipt of the Call Re¬ 
quest by the called DTE, the specified logical chan¬ 
nel is designated as being in the DTE Waiting 
state. The packet is then transmitted to the destina¬ 
tion DCE. 

The destination DCE transmits an Incoming 
Call packet to the originating DTE and places the 
logical channel in the DCE Waiting state. 

The called DTE indicates its willingness to 
accept the call by transmitting a Call Accepted 
packet across the DTE/DCE interface. The Call 
Accepted packet specifies the same logical channel 
that is indicated by the Incoming Call packet. This 
places the specified logical channel in the Data 
Transfer state. (The logical channel at the calling 
DCE is still in the Wait state.) 


Figure 4. 

X.25 User and Network Software Relationships 



Communications 

Public Packet- 


Facility 

Switching Network 


DCE 



Physical Interface 
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Figure 5. 

X.25 Packet Header Format 


-Octet 1 




-Octet 2- 




-Octet 3- 




IHHIH 

mum 

Bits 

1 2 3 4j 5 6 7 8 

1 2 3 4 5 6 7 8 

1 2 3 4 5 6 7 8 


1 

Logical 1 General 
Channel \ Fomat 

Logical Channel Number 

Packet Type Identifier 


Group i Idenifier 
Number | 

i 




A Call Connected packet is then sent by the 
DCE to the calling DTE and sets the logical chan¬ 
nel status to the Data Transfer state; the logical 
channel is then ready for transfer of data packets. 
This applies only for virtual circuit connections; 
for permanent virtual circuit connections, the as¬ 
signed logical channels are always in the Data 
Transfer state. 

It is possible for a DCE to receive a Call Re¬ 
quest (from a DTE) and an Incoming Call (from 
the network) simultaneously, with both messages 
specifying the same logical channel. This is called a 
call collision; when a collision occurs, the DCE 
cancels the Incoming Call and proceeds to process 
the Call Request. 

Data Transfer. Once the logical channel is in 
the Data Transfer state, data, flow control, or reset 
information packets can be transmitted. 

The Data packet format includes the packet 
send and receive sequence numbers. The calling 
DTE can transmit up to a predetermined number 
of packets before requiring a response. This num¬ 
ber is referred to as the window. All packet net¬ 
works must accommodate a lower window edge of 
at least eight, permitting at least seven packets to 
be outstanding before an acknowledgment is re¬ 
quired. The upper window value (the maximum 
number of outstanding packets) may not exceed 
127 (modulo 128). 

Upon receipt of an authorized packet, the 
receiving device can either authorize additional 
transmission by transmitting a Receive Ready 


packet to the sending device or deny authorization 
to transmit by issuing a Receive Not Ready packet. 

When transmitting Data packets, the Inter¬ 
rupt packet can bypass flow control (authorization 
procedures). A DTE can transmit an Interrupt 
packet to another DTE. To avoid swamping the 
receiver with Interrupt packets, the sender cannot 
send a second Interrupt packet until the first Inter¬ 
rupt packet is acknowledged by an Interrupt Con¬ 
firmation packet. 

While Data packets or Interrupt packets are 
being transmitted, issuing a Reset Request packet 
can reset the call. A DCE initiates a reset by issuing 
a Reset Indication packet. In either case, the logical 
channel is placed in the Data Transfer state. Any 
Data, Interrupt, Receive Ready (RR), or Receive 
Not Ready (RNR) packets in the network at the 
time of reset are ignored. If a DTE and DCE trans¬ 
mit Reset packets simultaneously, a reset collision 
occurs. The net effect is to place the logical channel 
in the Data Transfer state, ready for Data and In¬ 
terrupt packets. 

A DTE or a DCE initiates a request for clear¬ 
ing (disconnecting) a logical channel. Upon confir¬ 
mation by the other device, the logical channel is 
placed in the Ready state. 

Error Handling (Packet Level): When an error 
occurs, the DCE transmits Reset, Clear, and Re¬ 
start indication packets to the DTE. Reset re¬ 
initializes a virtual call or permanent virtual 
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Table 7. Packet Types and Their Use in Various Functions 

Function 

Packet Type 

From DCE to DTE From DTE to DCE 

Switched 

Virtual 

Circuit 

Service 

Perm. 

Virtual 

Circuit 

Call Setup and Cleaning 

In Incoming Call 

Call Request 

X 



Call Connected 

Call Accepted 

X 



Clear Indication 

Clear Request 

X 



DCE Clear 

DTE Clear 




Confirmation 

Confirmation 

X 


Data and Interrupt 

DCE Data 

DTE Data 

X 

X 


DCE Interrupt 

DTE Interrupt 

X 

X 


DCE Interrupt 

DTE Interrupt 




Confirmation 

Confirmation 

X 

X 

Flow Control and Reset 

DCE RR (Receive 

DTE RR 

X 

X 


Ready) 

DTE RNR 

X 

X 


DCE RNR (Receive 

DTE REJ* 

X 

X 


Not Ready) 

Reset Request 

X 

X 


Reset Indication 

DTE Reset 




DCE Reset 

Confirmation 

X 

X 


Confirmation 




Restart 

Restart Indication 

Restart Request 

X 

X 


DCE Restart 

DTE Restart 




Confirmation 

Confirmation 

X 

X 

Diagnostics 

Diagnostics 


X 

X 


circuit. Reset removes all Data and Interrupt pack¬ 
ets on the logical channel and resets the lower win¬ 
dow edge to zero. It affects only one logical channel 
number (one user). Reset procedures, which apply 
only in the Data Transfer state, handle specific er¬ 
ror events, such as local procedure error, remote 
procedure error, network congestion, incompatible 
destination, network out of order, etc. Clear affects 
only one logical channel number (one user). It 
clears a session when, for example, the host or host 
link crashes. In this case, the network initiates 
Clear procedures on the terminal link. It effectively 
logs off the terminal user. Clear resets the lower 
window edge to 0. Restart affects all users (all logi¬ 
cal channels on a given link) and clears all calls on 
that link. Restart is used when a failed link returns 
to service; it makes sure that all calls were cleared 
when the link went down. Restart also is used 
when either side (DTE or DCE) reports error con¬ 
ditions at the packet level; the good side initiates 
the restart procedures. 

In some networks, a diagnostic packet indi¬ 
cates unusual error conditions. A diagnostic packet 
from the DCE provides information on events that 
are considered unrecoverable at the packet level; 
the information permits the DTE to analyze and 
initiate recovery by higher levels. No confirmation 
is required on receipt of a diagnostic packet. 
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Implementation Considerations for Users 

X.25 recognizes that DTEs differ in their degree of 
sophistication. A simple DTE may have fixed 
packet formats and built-in parameter values, 
while a sophisticated DTE may work with varying 
packet formats and provide variable parameters to 
take advantage of the many network functions and 
signaling capabilities offered. 

At the physical level, the transmission rate 
DTE uses to access an X.25 network should be 
governed by the throughput and response time re¬ 
quirements of the user. Factors to consider include 
the maximum number of virtual circuits operating 
simultaneously and traffic characteristics of 
throughput-critical and response-time-critical vir¬ 
tual circuits. 

At the link level, Link Access Procedures 
(LAPs) and Link Access Procedures Balanced 
(LAPBs) are defined. A DTE might implement 
only LAPB. Parameters that are part of the LAPB 
procedures can be set to constants for all network 
connections. For example, a timer (Tl) may be set 
according to the slowest required line speed; a con¬ 
stant such as three seconds may be used. Also, the 
maximum permitted number of unacknowledged 
I-Frames (information frames) may be determined. 
The network provider must agree to this. All net¬ 
works support a window of at least seven I-Frames. 
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The maximum packet size (number of bits) of the 
I-Frame must also be established. 

If the DTE handles certain character sizes 
(octets), the frame level should be capable of ac¬ 
commodating any number of bits correctly (gener¬ 
ate acknowledgment, calculate frame check 
sequence). How such a properly received frame is 
processed depends on the individual system and 
may include actions such as discarding the frame, 
padding it, clearing the call, or resetting. 


Connections between Packet Switched 
Data Networks 

CCITT Recommendation X.75 describes the pro¬ 
cedures for the interconnection of packet switched 
networks. Many public packet switched data net¬ 
works support X.75 procedures, including AT&T 
Accunet, TransCanada’s Datapac, Graphnet Free¬ 
dom Network II, US Sprint’s SprintNet, and 
WangPac networks. 

X.75 is similar to X.25 in that it specifies pro¬ 
cedures* for the physical, link, and packet levels. 
Signal Terminal Equipment (STE), which acts as a 
bridge node between networks, implements X.75 
procedures. A related standard, CCITT X. 121, de¬ 
fines the international numbering plan for public 
data networks. 

Recommendation X.75 

Recommendation X.75, Terminal and Transmit 
Call Control Procedures and Data Transfer System 
on International Circuits Between Packet-Switched 
Data Networks , provides the rules for transmitting 
data between different data networks. The basic 
system structure is made up of communicating ele¬ 
ments that function independently. These elements 
include the physical circuits, which comprise links 
A1 or G1 (as defined in X.92), and a set of me¬ 
chanical, electrical, functional, and procedural in¬ 
terface characteristics; packet transfer procedures, 
which operate over the physical circuits and pro¬ 
vide for the transport of packets between STEs; 
and packet signaling procedures, which use the 
packet data transfer procedures and provide for the 
exchange of call control information and user traf¬ 
fic between STEs. Figure 6 shows the basic system 
structure of the signaling and data transfer proce¬ 
dures. The international link is assumed to be data 


link A1 and/or data link G1 as defined in Recom¬ 
mendation X.92. The international link should be 
capable of supporting full-duplex operation. 

Link-level packet transfer procedures between 
STEs consist of the Single Link Procedure (SLP) 
and the Multilink Procedure (MLP). The SLP is 
used for data interchange over a single physical 
circuit between two STEs. When multiple physical 
circuits are used in parallel, the SLP is used inde¬ 
pendently on each circuit. The MLP is used for 
data interchange over multiple parallel links. The 
MLP may be used over a single link when the com¬ 
municating parties agree to this procedure. Trans¬ 
missions are full duplex. SLP is based upon the 
Link Access Procedure Balanced (LAPB) as de¬ 
scribed in X.25 and uses the principle and termi¬ 
nology of the International Organization for 
Standardization’s (ISO’s) High-level Data Link 
Control (HDLC). For SLP, either modulo 8 (non- 
extended mode) or the modulo 128 (extended 
mode) may be used. The MLP is based on the mul¬ 
tilink procedures specified by the ISO and per¬ 
forms the functions of distributing packets across 
available SLPs. 

Three channel states are defined: the link 
channel state, which provides transmission in one 
direction; the active channel state, which means 
that the incoming or outgoing channel is receiving 
or transmitting a frame; and the idle channel state, 
which means that the incoming or outgoing chan¬ 
nel is receiving or transmitting at least 15 contigu¬ 
ous 1 bits. 

Data is transmitted in frames. Each frame 
must contain an Openin&Flag (8 bits), an Address 
field (8 bits), a Control field (8 bits), a Frame 
Check Sequence (FCS) field (16 bits), and a Clos¬ 
ing Flag (8 bits). An Information field of an un¬ 
specified number of bits, which follows the Control 
field, is optional. 

The Control field contains a command or re¬ 
sponse, and sequence numbers if applicable. Con¬ 
trol field formats may be one of three types: 
numbered information transfer (I format), num¬ 
bered supervisory functions (S format), and un¬ 
numbered control functions (U format). The I 
format performs information transfer functions. 
The S format performs link supervisory control 
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functions, such as acknowledging I frames, request¬ 
ing transmission of I frames, and requesting a tem¬ 
porary suspension of transmission of I frames. The 
U format provides additional link control func¬ 
tions. 

Each I frame is numbered sequentially. The 
send state variable V(S) represents the sequence 
number of the next in-sequence I frame to be trans¬ 
mitted. The value of the V(S) is incremented by 
one with each successive I frame transmission but 
cannot exceed N(R) of the last received I or S for¬ 
mat frame by more than the maximum number of 
outstanding frames. The send sequence number 
N(S), contained only in I frames, is set equal to the 
value of V(S). The receive state variable V(R) rep¬ 
resents the sequence number of the next in¬ 
sequence I frame expected to be received. The 
value of V(R) is incremented by one when an error- 
free, in-sequence I frame whose N(S) equals V(R) 
is received. Both I frames and S frames contain the 
receive sequence number N(R). N(R) is the ex¬ 
pected send sequence number of the next received 
I frame. When the STE transmits N(R), it indicates 
that all I frames numbered up to and including 
N(R)-1 have been received correctly. 

All frames contain the Poll/Final (P/F) bit, 
which is referred to as the P bit in command 
frames and the F bit in response frames. The STE 
solicits a response from another STE by setting the 
P bit to 1; the answering STE responds by setting 
the F bit to 1. The following commands and re¬ 
sponses are supported: 
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• Information (I) command —transfers sequen¬ 
tially numbered frames that contain an infor¬ 
mation field; 

• Receive ready (RR) command and response — 
used by the STE to indicate that it is ready to 
receive an 1 frame or to acknowledge a previ¬ 
ously received I frame; 

• Receive not ready (RNR) command and 
response —used by the STE to indicate a busy 
condition; 

• Reject (REJ) command and response —used by 
the STE to request retransmission of I frames 
beginning with frame numbered N(R); 

• Set asynchronous balanced mode (SABM) 
command —an unnumbered command used to 
set the addressed STE in the asynchronous bal¬ 
anced mode information transfer phase; all 
command/response control fields are one octet 
(eight bits); 

• Set asynchronous balanced mode extended 

(SABME') command —an unnumbered com¬ 
mand used to set the addressed STE in the asyn¬ 
chronous balanced mode information transfer 
phase; all numbered command/response control 
fields are two octets; all unnumbered command/ 
response control fields are one octet; 

• Disconnect (DISC) command —terminates the 
previously set mode; DISC indicates that the 
STE transmitting DISC is suspending opera¬ 
tion; 


Figure 6. 

Basic System Structure of X.7S Signaling and Data Transfer Procedures 
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• Unnumbered acknowledge (UA) response —used 
by the STE to acknowledge mode-setting com¬ 
mands; 

• Disconnected mode (DM) response —reports STE 
status when it is logically disconnected from the 
link and is in the disconnected phase; and 

• Frame reject (FRMR) response —indicates an 
error condition that is not recoverable by re¬ 
transmission of the frame. 

Packet-level signaling procedures relate to the 
transfer of packets at the STE-X/STE-Y (X/Y) in¬ 
terface. Recommendation X.75 specifies signaling 
procedures for virtual call setup and clearing, for 
permanent virtual circuit service, for data and in¬ 
terrupt transfer, for flow control, and for reset. 

Logical channels are used to complete simul¬ 
taneous virtual calls and/or permanent virtual cir¬ 
cuits. A logical channel group number and a logical 
channel number (in the range 0 to 15 inclusive and 
0 to 255 inclusive, respectively) are assigned to 
each virtual call and permanent virtual circuit. The 
logical channel group number and the logical chan¬ 
nel number are contained in each packet type, ex¬ 
cept restart packets. 

The procedures for virtual call setup and 
clearing are used only when a logical channel is in 
the packet level ready (RL) state. If call setup is 
possible, and no call or call attempt exists, the logi¬ 
cal channel is in the ready (PL) state (within the 
RL state). Call setup is initiated when the STE 
sends a call request packet across the X/Y inter¬ 
face. The call request packet specifies a logical 
channel in the PL state. The logical channel is then 
placed in the call request state. The called STE in¬ 
dicates acceptance by the called DTE by sending a 
call connected packet across the X/Y interface. It 
specifies the same logical channel as that requested 
by the call request packet. The logical channel is 
then placed in the flow control ready (DL) state 
within the data transfer (P4) state. 

A logical channel (in any state) can be cleared 
when the STE sends a clear request packet, which 
specifies the logical channel, across the X/Y inter¬ 
face. Upon receipt of a clear request packet, STE-X 
or STE-Y frees the logical channel and transmits a 
clear confirmation packet that specifies the same 
channel. This places the logical channel in the 
ready state within the RL state. Permanent virtual 
circuits require no call setup or clearing. 


Data transfer procedures apply independently 
to each logical channel at the X/Y interface. In the 
data transfer (P4) state, data, interrupt, flow con¬ 
trol, and reset packets may be sent and received by 
the STE. The data transfer state exists within the 
packet-level ready state of a logical channel. Each 
data packet contains a sequence number called the 
packet send sequence number P(S); only data pack¬ 
ets contain the P(S). 

The procedures for flow control and reset ap¬ 
ply only in the data transfer state. Flow control ap¬ 
plies to data packets. A window is defined for each 
direction of transmission at the X/Y interface. The 
lowest number in the window is called the lower 
window edge. The maximum window edge does 
not exceed modulo 8 or 128, is unique to each logi¬ 
cal channel, and is reserved for a period of time. 
For a particular call, two window sizes, one for 
each direction of transmission, may be selected. 
The packet receive sequence number P(R) (modulo 
8 or 128) conveys information from the receiver 
for the transmission of data packets. The P(R) be¬ 
comes the lower window edge when transmitted 
across the X/Y interface, thereby authorizing addi¬ 
tional data packets to cross the X/Y interface. 

Reset procedures are used to reinitialize a 
single call and apply only in the data transfer state. 
The STE sends a reset request packet that specifies 
the logical channel to indicate a request for reset. 
The logical channel is placed in the reset request 
state. The requested STE confirms by sending a 
reset confirmation packet, which places the logical 
channel in the flow control ready state. 

Restart procedures are used to clear all calls 
simultaneously. When the STE sends a restart re¬ 
quest packet, the X/Y interface for each logical 
channel is placed in the restart request state. In this 
state all packets, except restart request and restart 
confirmation packets, are discarded by the X/Y 
interface. An STE confirms by sending a restart 
confirmation packet, which places all channels in 
the ready state. 

Packet formats are based on the general struc¬ 
ture of packets as defined in X.25. 


Trends in Packet Switching 

Support for packet switching has grown among 
U.S. manufacturers of data processing and data 
communications equipment in recent years. For 
example, nearly all major computer vendors have 
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incorporated X.25 interfaces into their network 
architectures. This is part of an overall trend in 
accepting international standards and the increas¬ 
ing availability of products conforming to these 
standards. 

The CCITT published revisions to the X Se¬ 
ries standards in 1984 and in 1989. Since that 
time, the ratification and publication of revisions 
has become a continuous, ongoing process. Since 
the major building blocks for X.25 were laid by 
1984, all subsequent changes have been, and will 
continue to be, relatively minor. Some post-1984 
changes have revolved around efforts to make 
CCITT X Series standards compatible with those 
of the International Organization for Standardiza¬ 
tion (ISO). Currently, discussions on how to pro¬ 
vide greater interoperability between various X.25 
networks is taking place. Major developments in 
packet switching today, however, center not 
around X.25, but around the development of new 
ISDN-related technologies, such as fast packet 
switching and frame relay, which support the inte¬ 
gration of voice, video, and data and much higher 
transmission speeds. This section discusses post- 
1984 changes to X.25 and its relationship to ISDN. 

Major Changes in 1988 Revisions 

In the 1988 revised standards, there were no 
changes at the physical and link levels. At the 
packet level, however, a new facility for redirecting 
calls, Call Deflection, was established. In 1984, the 
CCITT had made available a new Call Redirection 
facility, allowing the network to redirect all calls 
destined for a given address. This redirection could 
occur when the destination was out of order or 
busy, or it could be based on time of day or other 
criteria. The 1988 facility extended this capability, 
allowing the destination subscriber to clear incom¬ 
ing calls to another party on a call-selective basis. 
The Clear Request packet contains the Call Deflec¬ 
tion information that profiles the desired alternate 
party. 

Relationship between CCITT and ISO Efforts 

CCITT X.25 packet-level protocol specifies a vir¬ 
tual circuit service; the ISO has issued a compati¬ 
ble version of the packet standard, ISO 8208. In 
recent years, CCITT and ISO organizations have 
worked on standards to carry longer addresses in 
the DTE field to facilitate interworking with ISDN 
(E. 164). 
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In 1988. the CCITT also modified the Ad¬ 
dress Extension facilities to be consistent with ISO 
address length. Previously, a provisional 32- 
decimal/16-octet field had been recommended: this 
address length was increased to 40 decimals/20 
octets. The ISO also added these address recom¬ 
mendations to Addendum 2 of ISO 8348 
(Connection-Mode Network Service): the CCITT 
adoption is X.213. 

Connectionless Issues: Relationships with ISO 
Efforts 

At any layer of the Open Systems Interconnection 
(OSI) Reference Model, two basic forms of opera¬ 
tion are possible: connection oriented and connec¬ 
tionless. Connection-oriented service involves a 
connection establishment phase, a data transfer 
phase, and a connection termination phase. A logi¬ 
cal connection is set up between end entities prior 
to exchanging data. In a connectionless service, 
typical of local area networks, each packet is inde¬ 
pendently routed to the destination. No connection 
establishment activities are required since each 
data unit is independent of the previous or subse¬ 
quent one. Each transmission mode has a niche 
where it represents the best approach. For exam¬ 
ple, file transfers may benefit from a connection- 
oriented service, while point-of-sale inquiries may 
be best served by a connectionless service. 

Traditionally, the CCITT has pursued a 
connection-oriented philosophy, while ISO has 
shown interest in connectionless. While the origi¬ 
nal OSI standard, ISO 7498, is connection ori¬ 
ented, ISO saw the need to provide connectionless 
service by issuing an addendum to that protocol, 
ISO 7498/DAD 1. ISO has issued a standard for 
connection-mode network service (ISO 8348), 
while the CCITT has issued an identical service, 
X.213. In regard to X.25 itself, however, ISO has 
decided not to pursue the connectionless service, 
formerly known as “datagram” service. X.75 is 
also a connection-oriented service; ISO has shown 
considerable interest in a connectionless internet¬ 
working protocol (IP) and has developed the ISO 
8473 to accommodate it. 

Packet Switching in ISDN 

The goal of the Integrated Services Digital Net¬ 
work (ISDN) is to provide an end-to-end digital 
path over a set of standardized user interfaces, giv¬ 
ing the user the capability to signal the network 
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through an out-of-band channel. (In contrast, in 
X.25, the user signals the network in in-band fash¬ 
ion by issuing packets such as CALL REQUEST, 
CALL ACCEPTED, etc.) 

Currently, different types of interfaces to the 
telephone network exist for different services. 
These interfaces include two-wire switched, two- 
wire dedicated, four-wire dedicated, DDS, and so 
forth. ISDN will provide a small set of interfaces 
that can be used for multiple applications. The 
CCITT has defined the following interfaces for 
ISDN: 

• 2B+D—two 64K bps channels and a 16K bps 
packet/signaling channel (also called the Basic 
Rate Interface). 

• 23B+D—twenty-three 64K bps channels and a 
64K bps packet/signaling channel (also called 
the Primary Rate Interface). 

• 3H0+D—three 384K bps channels and one 
64K bps packet/signaling channel. 

• Hll—nonchannelized 1.536M bps. 

• H12—nonchannelized 1.920M bps. 

• Multislotted—multiples of 64K bps channels 
(up to 1.536M bps) under the customer’s con¬ 
trol. 

• Broadband—high data rates, based on an ap¬ 
proach called synchronous optical network 
(SONET), building on multiplex of 51.84M bps. 
SONET standards negotiations began in 1986. 
The CCITT approved phase I of the standards 
in 1988 and phase II in 1989. This architecture 
has been called Broadband ISDN, in contrast to 
the other interfaces that have been considered 
part of Narrowband ISDN. 

With the exception of Broadband ISDN, all of the 
above interfaces could be carried on unloaded cop¬ 
per loops. Using fiber has also been considered, as 
it would make the local loop more robust. Out-of- 
band signaling makes possible a new class of ser¬ 
vices. In addition, the 16K bps D-channel will be 
connected directly to the BOC’s packet switched 
network, providing the subscriber with the data 
multiplexing advantages packet switching offers. A 
major effort is under way in Europe to bring the 
system to market. In the United States, several tri¬ 
als have been undertaken, and limited ISDN ser¬ 
vice is already available. 


CCITT ISDN Standards 

ISDN provides a specific protocol that users can 
employ to signal the network. Currently, a three- 
layer protocol suite is defined. At the Basic Rate, 
the Physical Layer manages a 192K bps, full- 
duplex bit stream using time-compression tech¬ 
niques and time division methods to recover the 
two B-channels and one D-channel. The remaining 
48K bps stream is used for Physical Layer control 
information. The defined standards are 1.420 (Ba¬ 
sic Rate Interface Definition), 1.430 (Basic Rate 
Interface Layer 1), 1.421 (Primary Rate Interface 
Definition), and 1.431 (Primary Rate Interface 
Layer 1). 

The Data Link Layer is not defined for trans¬ 
parent B-channels used for circuit switched voice 
or data, but it is defined for the D-channel. For 
Narrowband ISDN, the D-channel employs a LAP- 
D Link Layer protocol, which is a subset of the ISO 
HDLC Data Link protocol, as specified in CCITT 
Recommendations Q.920 (1.440) and X.921 
(1.441). It provides statistical multiplexing for 
three channel types: signaling information for the 
management of the B-channels; packet switched 
service over the D-channel; and optional channels, 
used for telemetry of other applications. 

The Network Layer protocol for the signaling 
channel is specified in CCITT’s Q.930 (1.450) and 
Q.931 (1.451) specifications. It provides the mech¬ 
anism for establishing and terminating connections 
on the B-channels and other network control func¬ 
tions. For the packet switched service over the D- 
channel, the Network Layer protocol is X.25. 
CCITT will define Layer 3 protocols for the op¬ 
tional channels in the future, or they will be speci¬ 
fied as national options. 

A technique is required for specifying 
whether user-to-network signaling, user packet 
data, or user telemetry data is being sent over the 
D-channel. This technique involves the use of a 
service access point identifier (SAPI). 

Each layer in the OSI Reference Model com¬ 
municates with the layers above and below it 
across an interface. The interface is through one or 
more service access points (SAPs). SAPs have a 
number of uses, including subaddressing for inter¬ 
networking situations, Transport Layer applica¬ 
tions, and for user data packet service over an 
ISDN D-channel. 

Considering the applications to the Transport 
Layer, one should note that two general types of 
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Figure 7. 

SAPI Action for a Basic Rate D-Channel 


Signaling Packet Telemetry 



addressing in a communications architecture are 
available. Each host on the network must have a 
network address, allowing the network to deliver 
data to the proper computer. Each process within a 
host must have an address that is unique within the 
host; this allows the Transport Layer to deliver 
data to the proper process. These process addresses 
are identified using SAPs. A similar approach is 
followed for ISDN. 

LAP-D, the data link standard for ISDN, 
specifies the link access protocol used on the D- 
channel. LAP-D is based on LAP-B, which is based 
on HDLC. LAP-D must deal with two levels of 
multiplexing. First, at a subscriber location, 
multiple-user devices may be sharing the same 
physical interface. Second, each user device may 
support multiple types of traffic, including packet 
switched data and signaling. To accomplish this 
type of multiplexing, LAP-D employs a two-part 
address consisting of a terminal endpoint identifier 
(TEI) and a SAPI. Typically, each user terminal is 
given a distinguishing TEL The SAPI identifies the 
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traffic type and the Data Link Layer services di¬ 
rected to Layer 3. For example, the SAPI value of 0 
directs the frames to Layer 3 for call-control proce¬ 
dures; a SAPI value of 16 indicates a packet com¬ 
munication procedure. See Figure 7. 

Fast Packet Switching 

Faster switches are required before packet¬ 
switching service is more widely used. Current 
packet switches can provide a throughput of up to 
40,000 packets per second. The fast packet¬ 
switching technique has drawn considerable inter¬ 
est, since vendors of fast packet products promise 
up to 800,000 packets per second throughput. Ac¬ 
cording to most sources, carriers throughout the 
world view fast packet technology as the technique 
of choice for future networks. 

In the fast packet environment, voice, data 
signaling, video, mass-memory transfers, and high¬ 
speed LAN interconnections are combined and 
channeled through a common physical network. 
This technology provides continuously adaptive 
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bandwidth management, allowing each user to ac¬ 
quire the requisite amount of transport capacity on 
an as-needed basis. 

Data packets produced by the fast packet 
technique are like samples produced through pulse 
code modulation (PCM). Since X.25 data packets 
can contain data only, traditional packet switching 
is not compatible with fast packet technology. Pro¬ 
prietary solutions are available, however, from 
Stratacom and other vendors, for integrating both 
types of systems. 

Frame Relay 

Frame relay is an emerging, standards-based ad¬ 
dressing technique that has great potential in fast 
packet swithing and internetworking of remote 
LANs. Frame relay is analogous to how X.25 re¬ 
lates to conventional packet-switching backbone 
networks. X.25 is a “network access method,” or 
user-to-network interface. Frame relay provides 
user access to a higher speed network that is based 
on a transmission technology other than X.25. 

Vendors have recently developed frame relay 
interfaces for conventional packet and circuit 
switched networks. LAN internetwork and WAN 
vendors are also teaming up to develop frame relay 
capabilities for remote bridges and routers, offer¬ 
ing integrated LAN/WAN solutions to customers. 

Frame relay is based on the CCITT Layer 2 
protocol developed for ISDN, Link Access Proto¬ 
col D (LAPD). Unlike conventional X.25 packet 
switching, frame relay uses variable packet lengths 
and performs error checking only at the remote 
end of transmission. Any errors occurring between 


intermediate network nodes are assumed caught 
and corrected by higher layer protocols. Thus, in¬ 
termediate nodes simply forward packets (called 
frames) without processing the datastream. In ad¬ 
dition, frames must be received in the order in 
which they were sent, unlike some X.25 networks, 
which involves considerably less machine process¬ 
ing at the opposite end of transmission. These effi¬ 
ciencies result in extremely higher throughput 
speeds—up to 2M bps. 

Most commercial frame relay products are 
based on ISDN recommendations contained in 
CCITT 1.122, entitled “Framework for Providing 
Additional Packet Mode Bearer Services,” and/or 
in ANSI T1S1/88-2242, “Frame Relay Bearer 
Service—Architecture and Description.” Cur¬ 
rently, only one packet service has been specified 
in ISDN standards: “Support of Packet Mode Ter¬ 
minal Equipment by an ISDN,” CCITT 1.462 
(X.31). More work is being accomplished during 
the 1989-1992 Study Period, however, to specify 
additional packet switched services. 

Vendors from several different networking 
disciplines are trying to establish themselves as 
frame relay proponents. These include T-carrier 
nodal processor vendors; LAN internetwork ven¬ 
dors (bridges and routers); traditional packet 
switched network providers, such as Hughes Net¬ 
work Systems, Netrix, Telematics, and US Sprint; 
and communications carriers. Many have an¬ 
nounced produpts or services that will be available 
in 1991. Stratacom is one vendor that has been 
instrumental in developing frame relay concepts 
(along with fast packet technology). ■ 
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